Packaged scripts are Selenese scripts together with any Settings and optional local
.html forms/pages. They usually also use a framework.
In SeLite these scripts validate functionality of Components and application-specific frameworks. They also serve as practical documentation, ready for inspecting at any detail in Selenium IDE.
To get SeLite packaged scripts, either
selenese-scripts, e.g. commands/selenese-scripts/. Each framework that comes with SeLite has suites in its subfolder
test_suites_and_cases, e.g. phpmyfaq/test_suites_and_cases/.
To make navigation across files easy, here’s a convention: filenames of suites end with
_suite.html, and cases are in files that have names ending with
_case.html. If there are several shared cases, they can be in
Scripts have SettingsManifests > Values manifests for any Settings. If the same component (add-on) has multiple suites that need different configuration, such suites and their values manifests are in subfolders.
Selenium IDE doesn’t indicate the current suite’s folder in the GUI. Therefore make suite file names clear. That helps especially when having similar suites in different folders (because of different configurations). SeLite own suites have file names in format
Cases of packaged scripts must refer to their local
.html forms/pages by file://-based URLs relative to location of the suite. Do not use URLs should not be relative to the case, because the same case can be shared by multiple suites.
Reasoning: A case can open local pages relative to its location, or to location of the current suite (the one loaded). Either choice has some positives, and can also be confusing. However, using URLs relative to the current suite allows flexible re-use of automation cases and their Selenese functions, with customised versions of local pages for each suite. If all such suites can use same version of a local page, such a file can be in a common parent folder. This results in similar suites having the same folder structure and same names for local pages, which simplifies navigation.
Suites that share cases from parent folder(s) should be at the same directory depth, so that they can access any local
.html files in higher folders through same relative URLs (e.g.
../page.html). Scripts open local forms/pages by e.g.
open | file://<> SeLiteSettings.getTestSuiteFolder() <>/form.html.
We indent commands in tests. That requires SeLite Clipboard And Indent. Otherwise run
sed -r -e 's/<td>( )+/<td>/' test-case-location >temp_out; cp temp_out >test-case-location.
If you need verify that a Selenese command fails under certain circumstances, put it within ``try..catch
of a try..catch..endTry
block as per [SelBlocks Global]. Use its catch..endTry
part to set a stored variable of your choice. Check that variable after endTry
(e.g. with getEval`) and if not set, throw an error. Remember to clear that stored variable before that block of steps, so that it can run multiple times.
There are real negative tests in e.g.
selite.sel-blocks-global/selenese-scripts-negative/. Those tests themselves are supposed to fail (e.g. they validate situations when
try..catch..endTry is supposed not to catch an error). If these tests don’t fail, then there’s a problem.
Before you run a script packaged with local forms/pages, the current tab in Firefox must be blank (or showing something loaded through file://… URL). If it shows anything from http:// or https://, the script will fail (it won’t be able to access any local files).
Open a suite using Selenium IDE menu File > Open… or Open Test Suite… Do not open actual cases via menu File > Open…, otherwise they won’t be able to access any local forms/pages (as per above) nor any shared Selenese functions. Then you can run the whole suite, or selected cases. Shared cases that only define Selenese functions are not intended as runnable.
In order to run the whole set of SeLite suites (except for
selite.sel-blocks-global/selenese-scripts-negative/), use Components > Run All Favorites. Import
SeLite/run-all-favorites.json. You need source of SeLite and SelBlocks Global to be in their default folders (
SelBlocksGlobal) under your home folder. Those folder names are the default when you check them out from GIT. If you download them instead, rename the folders to
These validate functionality
There’s no extra installation - they come as a part of their components (in folders
These are invoked from shell (i.e.
cmd on Windows). They only exist for Extension Sequencer > Shell tests.