Page History
...
Recording with Selenium IDE
Selenium IDE records the events generated by the user in a Test Case as Selenium commands (clicks/ typing/ keyboard events..).. Each command is targeting a specific element of the DOM (The HTML tree generated by the rendering of the Web Client) using the default Locator Builder; the default is the wicketpath locator if it has been correctly placed on top of the Locator Buillder list.
Just recording is not enough for a correct playback of the Test Case. To validate the test should be added UI verification checks. Is the element present after i have clicked the button ? is the result value equal to the expected value ?
When recording Selenium IDE assumes that all the elements are already present in the DOM but this is not always the case. Selenium IDE is asynchronous therefore is necessary to add an explicit command to put Selenium waiting until the result of the triggered action is received. For example a click on the button 'next record' result in showing the next record of the foundset. The result of the action is not immediate therefore the expected value cannot be immediately target with Selenium. Selenium should wait until the result of the click action is complete before targeting the values of the next record. Use the commands waitFor to wait a specific element or a specific value to be loaded on the page.
Recording Events
- Click record button
- Go to WC, do the actions needed, typing data / adding records / delete
- When done go to selenium and hit Stop recording button
- A sequence is created which can be saved using CTRL+S
...
Plugins and add-on for Selenium IDE
Many plugins are available for Selenium IDE as Firefox add-on. Listed below some nice to have plugins.
...
Select the proper locator
- The selection of a stable locator is the most important step to have a maintainable test script. Element's locator can change frequentely in the DOM resulting in an unmaintenaible test. When recording the Test Case the developer should choose the locator that most likely will not change when modifying the form.
...
- Is a good practice to store the locator of often used element into Selenium variables. If the locator is then affected by any change would be easier to set the new locator in the test script. In such a way the Test Case becomes also more readable.
ID locator
Target the element having the specific ID. Is the most fragile type of locator since in the Web Client the markup Id of elements change frequentely.
Wicketpath
Target the element using the servoy wicketpath attribute of the element.
Is a stable locator for forms generated with Servoy at Design time; the wicketpath will not change at any edit of the form. The wicketpath is not stable instead when the form or Servoy element is generated at Runtime using the Solution Model. In this case will change at any execution.
Example: //div[@wicketpath='servoy__page_servoy__dataform_forms_0_webform_servoywebform_View_sv____BC22D853__A837__4D0B__8937__8ED2D086451E_sv____F48C87B8__E69A__46D1__93C2__33F59B96538E__wrapper']/input
...
XPath: position
Target the element using the exact position of the element in the DOM. This type of locator is unstable for any change happening in the structore of the page but can be use to target element generated with the Solution Model (Note that the Solution Model should always generate the same result otherwise the DOM of the page will look different and most likely the locator will break)
Example: //div[13]/div/div/div[3]/div
XPath: contains text/property
Target the element containing the specific text or the specific property. Resist to changes made to the form at Design time and even to the solution model. Fails if there are multiple elements containing the same text or the same property or if the text/property is changed.
Examples
//div[text()='logout']/../.. find the parent of the parent of the div element having the text equal to 'logout'
//img[contains(@src, "pv_btn_logout.png")] find the element containing the value "pv_btn_logout.png" in the src attribute
FormName-ElementName
Servoy has in it's road map the possibility to provide a Selenium locator based on formName/elementName values which would be more resistant to failure then the mentioned selectors.
Keep the test maintainable
- Store frequently used values in variables.
- Avoid duplicates in the test scripts. Modulate the Test Cases and Test Suites and reuse same Test Cases in multiple Test Suites. Create new extentions or Rollup for frequently used sequence of commands.
- Keep the Test Case and the Test Suites small. Each Test Suite should test a single Use Case. Separate the Test Suite in multiple Test Cases, each Test Case is a single Unit of test.
Example: create new customer. Create a Test Suite and the following Test Cases: Login, Open form customers, create customer, logout. - Refactor the test when refactoring the code or changing the form.
- Document the tests. Use proper naming conventions and save the Test Suite and Test cases in a organized folder structure.
- Use setUp and tearDown functions to make the test repeatable. Avoid using other Test Cases as setUp or tearDown, if the test case of the setUp fails then the setup will not be correct. Use Servoy functions as setUp or tearDown. Is possible to inject wicket callback to the Servoy functions into the client libraries. Once the wicket callback is correctly injected execute from Selenium with the command runScript
Overview
Content Tools
Activity