Click through the examples below to access descriptions of how to create your own intelligent modules for your tests.
If you want to click something in your AUT, then most of the time, just the simple “click” action will do. Sometimes, though, you might want a click that’s a bit more intelligent, one that includes a few checks and some synchronization.
The action “replace text” from the library is the most likely one you’ll use if you are entering text on a component. In some cases, you may want to perform some checks before doing the replace.
If the “replace text” action provided doesn’t work on your AUT, or if you need a module that does something slightly different, then it’s easy to create a module that will perform the individual steps as you need them.
There is an action in the library to replace the text on a table cell that you specify based on its row and column. Sometimes, though, you may want to navigate to the cell using its value, or your table may have a different mechanism for editing text than the one supported in the available action. You can create a module that selects the cell you need, edits the text and then checks the result.
Synchronizing tests using progress dialogs is a good way to ensure that your test will wait until the AUT is ready. However, there are some progress dialogs whose behaviour is not always foreseeable – they only appear if the action will last longer than, e.g. 3 seconds. This is an example of a module that will help you to synchronize your test in the most dynamic way possible, without having to know whether a progress dialog will appear or not.
In the library of actions, there are various actions to wait dynamically for components, windows, windows to close, and the menu bar. If you want to wait for e.g. a text to change in a status bar, then you can create a module that will wait dynamically for the desired text to be shown. If you have a status bar that will show “connected” when a connection has been made, and “connecting” while the program is working, then you can wait for the text “connected” like this:
In Swing and .NET applications, file dialogs (for opening, saving, etc.) are written in the same toolkit as the rest of the application. In SWT and RCP applications, however, the file dialogs are native, and therefore not Java – the actions to wait for windows, replace text, and click buttons will not work.
Fortunately, we’re not usually that interested in testing the system dialogs; we just want to use them in the test to achieve our goal of opening or saving something. To do this, you can use a module like this:
This example shows you how to react to a dialog that may or may not come during a test (e.g. a save prompt dialog will only come if there are unsaved changes). You can also use modules like this to conditionally login to your application for example.