Test Project
All tests in CubicTest must reside in a CubicTest test project. The project is created in the CubicTest perspective in Eclipse.
Example test project:
Test
A test in CubicTest tests a single or multiple requirements of a web application. It is modeled as a series of pages/states with transitions (user interactions) between the pages/states.
A test can be used for:
- Requirements testing
- Requirements specification (test driven development)
- Bug reports
- Change request (test driven development)
Example test that tests the log-in functionality of a web shop:
The blue squares are pages/states and the arrow is a transition (user interaction) between the two pages/states.
The "Username", "Password" and "Log in" elements are form elements (asserted present and basis for user interaction, as explained below).
Page/State
A web application typically has several pages/states. In CubicTest, a page/state is a stable view of the application that the user can interact with.
The user can advance to a next page/state by interacting with the application.
When JavaScript or Ajax is used, the state of an application can change frequently, such as during mouse position and text typing. The resulting changes is modeled as a new page/state.
Example page/state (asserts the presence of four "page elements"):
The title of the page/state (top part in blue) serves as a logical name to increase readability. The four elements within the page/state are called "page elements", more info on that below.
Transitions and user interactions
While a page/state represents a stable view of the application, transitions represents how this page/state is changed to get to the next page/state in the test.
A transition can contain one or more "user interactions", which are applied in sequence to trigger the next page/state.
Example user interactions that can be part of a transition:
- Fill out a text field
- Click a link
- Click a button
- Mouse over a page element
- Select an option in a select list
Example transition with three user interactions (fill in username, fill in password and click the "Log in" button. The latter of which should trigger the transition to the new state):
The arrow symbolizes the transition and contains the three user interactions. The transition is not considered applied untill all user interactions are applied to the page/state.
Setting the timeout for getting the result:
Default timeout for asserting presence of the result of the user interaction is 20 seconds.
This can be changed in the properties tab of the user interaction. There you can set the timeout for all subsequent pages of the user interaction.
If set to other than default, the timeout is valid for all subsequent pages and page element assertions of the test. To set it back to 20 seconds, specify it in the properties tab of a subsequent user interaction.
The common default test-project timeout of 20 seconds can be changed in the file test-project.properties.
Page Elements
These are used to assert the presence of things on the page/state, and as basis for user interactions.
Each page element has a set of identifiers that identify the element on the page (see own chapter below). Each element also has a set of user interactions that can be applied to it.
To test that an element is not present, there is possible to mark an element as "should not be present".
The following is a list of the available page elements in CubicTest (available in the "palette" of the test editor):
When a page element is added to a page/state, it looks like the following (asserting the presence of four elements):
Contexts
Contexts make it easy to identify elements by specifying neighboring elements, and are used when elements are hard to identify uniquely by themselves.
Example:
| There are many "Buy" buttons on a page, and it is hard to identify which one to press to buy a particular product. We want to press the "Buy"-button that is in the same row as the text "Foo". |
Contexts in CubicTest makes this possible. Contexts are similar to other page elements, but identify a part of the page (e.g. a table, DIV, table row etc).
Specify a context and put some elements in it that together forms a unique combination, and they will be identified on the page.
Contexts have a set of identifiers in the same way as page elements have, but they do not need to be unique as the child elements of the context help identify the context itself. But it is a good idea to provide some identifiers to the context as well (especially element name, e.g. "tr" for table row).
Contexts do not need to be the direct parent of its elements, it only has to be an ancestor. Thus detailed knowledge of the page structure is not needed.
To sum up, a Context has the following meanings:
- It should be present on the page
- It should contain all child elements that are specified to be in it
Good candidates for contexts are (any parent element is possible to use):
- Rows
- DIVs
- Tables
Example: A table with a row in it, containing a link and a button. The hierarchical structure and sibling elements gives unique identification. All elements can have additional identifiers, but it may not be needed. Only "element type" - table and tr - are used in this case (not shown).
Example shown in the graphical test editor:
Context used to identify which "Buy" button to press (here the "Buy" button does not need any identifiers, as the "Shipping crate" link identifies which row is meant):
Contexts can also be used as a general purpose element e.g. for elements that are not present in the Palette in CubicTest. E.g. for HTML <button> elements (the non-form input version).
Identifiers
A page element or context can be identified by a set of identifiers found in the HTML source.
Examples of identifiers (not all are applicable to all elements):
- ID
- Name
- Href
- Src
- CSS class
- Tooltip
CubicTest supports providing multiple identifiers at the same time, and a logical "AND" is applied between them, meaning that all must be satisfied.
An element can also be placed in a context to identify it (or it can be both in a context and have some identifiers itself).
In addition, each identifier can have one of the following moderators on its value: "be equal to", "contains", "starts with" or "ends with". This is handy when only part of the identifier value is known or possible to assert.
Example of a set of identifiers for the selected "Buy"-button (moderators not shown):
Start Points and Extension Points
A test can start by either invoking a URL or by starting from an "Extension point" in another test.
In general, it is possible to define an extension point at any page/state in a test, and other tests can continue (start from) this state. In this way, interactions and assertions common to more that one test do not have to be duplicated such that a bootstrapping does not have to be duplicated in all tests.
Example of a "URL start point" that starts from "http://localhost:8080/cubicshop/":
In this test we also define an "Logged in" extension point that other tests can start from.
Example of how this extension point can be used as the start point of another test:
!extension_start_point.png!
Here we start from the "Logged in" state defined earlier, and continue with a test that asserts and clicks a webshop link (rest of test omitted).
To change the start point of an existing test, right click on the start point and click "Change start point for test".
Commons
A Common is a virtual page/state used for testing the same assertions on multiple pages.
Example using a Common for checking the presence of the main navigation links:
Commons are found in the Palette just as pages/states. To connect a Common to a page/state, drag and drop a Connection from the Palette from the Common to the page/state.
Elements from a Common can also be the subject of user interactions.
Sub Tests
A test can be included in another test. This is using the test as a sub test.
Subtests are connected just as a page/state, and will be executed fully or to a defined extension point.
To add a subtest to a test, drag and drop a test from the "package explorer" into the Graphical Test Editor of another test.
Example test using four subtests:
Dedicated sub tests using Sub Test Start Points:
Any test can be used as a sub test, but the most suitable sub tests are tests without their own setup-logic (i.e. without URL or Extension start points) such that they can be used in different settings and test scenarios.
To create a dedicated sub test,
- Right click in the CubicTest package explorer,
- New -> New CubicTest Test
- Choose "Sub test start point" as start point type in step 2 of the wizard.
The new test will have a Sub Test Start Point, and cannot run stand alone (has no URL or Extension start point), it must be used as a sub test in a higher level test that contains a proper start point.
The start point can be changed to another type of start point by right clicking in the Test and choosing "Change start point of test".
Test suites
There are two types of test suites. Custom Test Suites (JUnit java classes) and visual test suites (.ats files).
See page Custom Test Suites (and flow control). The rest of this section is a description of visual test suites:
Visual Test suites are special tests that start with a "Test suite start point" and they typically reside in the provided "test suites" folder.
Visual Test suite files have the extension *.ats. The main difference between a test suite and a normal test is the start point, which does not invoke any URL or previous test.
To create a test suite, right click on a folder (typically the "test suites" folder) and select "New -> New CubicTest test suite".
To add tests to the test suite, drag and drop tests from the Package Explorer into the Graphical Test Editor of the test suite and connect them with connections, starting from the start point. Test suites can be run / exported in the same way as normal tests.
Example test suite:
