Custom Test Steps
Custom Test Steps provide you the possibility to write custom code to be executed during a test run. E.g. for doing assertions or interactions that are not possible to model with the Graphical Test Editor in CubicTest.
A Custom Test Step in CubicTest consists of two things:
- A generic Custom Test Step definition (element in the Graphical Test Editor) which defines the name and description of the custom test step and which can define a set of input parameters to the step.
- Implementation(s) of the step (chunks of code), max one implementation per exporter plugin.
The Custom Test Step feature is fully pluggable, i.e. you can in theory write an implementation of a Custom Test Step in all available CubicTest exporter plugins -- if the plugin provides an editor for it.
Example: A Custom Step for typing today's date in an input field can take the input field ID as parameter and populate the field. To make sure that the test runs with both Selenium and Watir, an implementation can be created for both.
As of version 1.8.11 only the Selenium Remote Control plugin for CubicTest has a Custom Test Step Editor.
To create a Custom Test Step:
- Right Click on a folder in the Package Explorer and select "New CubicTest Custom Test Step" (you might want to create a seperate folder for all your custom test steps)
- Provide a name and file name for the custom test step. Press Finish.
- In the Custom Test Step definition page that opens, you can create implementations of the step and define parameters. The blue links are for creating implementations.
To add a Custom Test Step to a Test:
- Drag and drop the Custom Test Step from the Package Explorer into the Graphical Test Editor
- Connect the step with a Page/State so that it can be reached.
The Selenium RC Java Custom Test Step Editor
This is an advanced implementation, with the following features:
- Add and use all the Java libraries you want
- Autocomplete and inline javadoc for the Selenium RC API
- Full Java debug support
To create an implementation:
- Click on the Cubic Test Selenium Extension link in the Custom Test Step definition page
- Provide a name for the Java Class to be created
- Write Java code in the class that opens. See the Selenium RC documentation for details of the API.
You will be writing an inplementation of the ICustomTestStep class.
This class has an "execute" method which you should implement. We expect you to use JUnit type assertions like assertEquals, etc. In this way CubicTest can handle the CustomTestStep assertion failures correctly. You can throw other kinds of exceptions as well.
Parameters to the execute method:
- "arguments" (key-value pairs) Key names are from Custom Step definition page and values from properties page in the Graphical Test Editor.
- "context" Shared Custom Step Context. Makes it possible to send messages from one custom step to another instead of using static variables. Is basically an empty HashMap until you decide to fill it up with something.
- "selenium" The Selenium Remote Control object.
The method can throw any type of exception or error. Handled by CubicTest. java.lang.AssertionError = step failed, others = test exception.
Example: Custom Test Step for selcting a browser window (e.g. a popup) based on a windowName parameter:
public class SelectWindow implements ICustomTestStep { public void execute(Map<String, String> arguments, IElementContext context, Selenium selenium) throws Exception { selenium.selectWindow(arguments.get("windowName")); } }
Logging and naming.
For logging, use the static methods of org.cubictest.core.facade.Logger.
The Logger logs to the available log system (Eclipse log system if running in Eclipse, otherwise Commons Logging).
If you want to log the name of a particular instance of a Custom Test Step being executed, create a name argument to the step and log the execution with the Logger class.
Important notes on browser timing
When entering the Custom Test Step, the Web Browser may not have loaded the page fully.
There are two strategies for handling this, depending on the type of application/page being tested (traditional or Ajax/JavaScript).
Custom Test Step after page reload (traditional web app style)
When testing traditional web applications, you can check the Wait for page to load before entering Custom Test Step checkbox in the Custom Test Step Editor.
The runner then waits for page to load using the timeout in seconds from the previous user interaction (the timeout for result setting). If no timeout is set explicitly on the previous user interaction, the timeout is gotten from an even earlier user interaction (if set). If no previous timeouts are set, the timeout value in the file test-project.properties is used, where the default value is 20 seconds.
Custom Test Step responding to Ajax or JavaScript
When testing Ajax/JavaScript pages, you cannot use selenium.waitForPageToLoad(..) since there is no page reaload to wait for.
Instead, use the CubicWait class to assert element presence with a timeout. Then the elements will be present and ready for interaction when the wait returns.
Example: To wait max 10 seconds for page element and then click on it:
new CubicWait() { public boolean until() { return selenium.isElementPresent(yourLocator); } }.wait("Page element not found: " + yourLocator, 10000); selenium.click(yourLocator);
