Hide last authors
| author | version | line-number | content |
|---|---|---|---|
 |
1.1 | 1 | [[Selenium>>http://en.wikipedia.org/wiki/Selenium_%28software%29]] is a portable software testing framework for web applications. Selenium provides a record/playback tool for authoring tests without learning a test scripting language. Selenium provides a test domain specific language (DSL) to write tests in a number of popular programming languages, including Java, Ruby, Groovy, Python, PHP, and Perl. Test playback is in most modern web browsers. Selenium deploys to Windows, Linux, and Macintosh platforms. |
| 2 | |||
| 3 | There are differing approaches to using Selenium in the Project WOnder community and code base. Tests can be written as tables in HTML or in a more concise format, a text file with the extension ".sel" where the parts of a command are separated by a '' character. Tests can be running using a Firefox extension called "Selenium IDE" or that can be run from the command-line using the "Selenium-RC" classes. Tests can be run from within a Project WOnder application using the ERSelenium direct action. Tests can also be run with an ant task or using the [[Hudson>>http://en.wikipedia.org/wiki/Hudson_%28software%29]] continuous integration system. | ||
| 4 | |||
| 5 | == Creating Tests == | ||
| 6 | |||
| 7 | Selenium uses a basic "action-wait-assert" pattern in testing the UI of a web application. Commands do one or more of these things. In general, "action" commands start with "click", "select" or "type", "wait" commands are "pause" or "waitFor", and the "assert" commands start with "assert" or "verify". Generally, every "assert" command has a "verify" counterpart, such as "assertText" and "verifyText". The difference is that if something is asserted and found not to be true, then the test will abort as the test fails. If something is verified and found not to be true, the the test will fail and the tests will continue to run. So, in order to write robust tests, one would want to verify if one can, but abort if a particular test failure will prevent the running of other tests. Note that a test failure may prevent the **correct** running of a set of other tests, but you may still want to let those tests run. More errors may lead to more information. There are also "store" commands that can be used to store and examine state in a running test. | ||
| 8 | |||
| 9 | A command has three parts: a name, a locator, and an optional parameter. Figuring out the names of desired commands is usually not difficult, though plugins can be added to Selenium that complicate the question. Writing locators is often the hardest part of test writing. There are different approaches to this that are described in the literature one will find. In general, locators will either find some text, and one needs to provide the text to find, or they will use xpath to find an element or reference the dom tree directly. Other strategies are documented as well. | ||
| 10 | |||
| 11 | One can use tools, such as the Selenium IDE, to record tests. This will result in some strange looking locators, but they will work. Or one can write web applications in such a way that important things are easy to find. The liberal use of "id" parameters on HTML tags, for example, will ensure this. It is arguably easier to record tests, and creating tests by recording them means that one does not have to change one's application, but the resulting tests will turn out to be somewhat fragile. Any change in the page source, regardless of whether or not it changes the meaning of a test, will probably necessitate a re-generation of the test. However, if one is using identifiers on the tags in the application, one can document the intent of the test. The page may be changed, but if the logical meaning of the elements does not change, then one may presumably not need to change the tests. Finding the right labels to use on the correct tags to mark up the logical structure of the page is, though, a skill that must be learned and some people will be better at it than others. | ||
| 12 | |||
| |
3.1 | 13 | For example, here is an example test in "Selenese": |
| 14 | \\ | ||
| |
1.1 | 15 | |
| 16 | {{code}} | ||
| 17 | |||
| 18 | |open|<a web page URL>|| | ||
| 19 | |assertText|Hello world|| | ||
| 20 | |click|link="Do you hear me?"|| | ||
| 21 | |pause|1200|| | ||
| 22 | |verifyText|Yes, I hear you.|| | ||
| 23 | |||
| 24 | {{/code}} | ||
| 25 | |||
| 26 | == Other References: == | ||
| 27 | |||
| 28 | * [[Selenium Introduction]] | ||
| 29 | * [[Project WONDER-Frameworks-ERSelenium>>WO:Project WONDER-Frameworks-ERSelenium]] | ||
| 30 | * [[How to Develop Selenium Tests]] | ||
| 31 | * [[Testing-Load Testing WO Apps with JMeter>>WO:Testing-Load Testing WO Apps with JMeter]] | ||
| 32 | * [[How to test a Diva app with Selenium>>WO:How to test a Diva app with Selenium]] | ||
| 33 | * [[Specifying Robust Selenium Element Locators]] |