A DZone Zone Leader discusses the Iridium language and how it can simply end-to-end testing by allowing the coder to use syntax very similar to that of English.
One of the primary goals of Iridium is to allow testers, business analysts, and developers to write end-to-end tests in a language that is as close to English as possible. The Gherkin Given/Then/And/When syntax (upon which Iridium is built) is a great place to start, but in and of itself only guides the steps that you can write rather than providing a hard and fast dialect that testers should use.
The challenge with Iridium has always been to expose a set of steps that allow fluid and natural interaction with web applications via WebDriver, while also resulting in feature files that are easy to write and read.
The first collection of steps followed the approach that I have seen used in most other Cucumber/WebDriver implementations, with steps that allow you to identify elements using things like CSS selectors, ID attributes, and XPaths. An example of these steps would be:
Identifying elements in this manner makes sense to a developer, but it is not how you would describe the interaction with a web application to another person. To understand why, take a look at this example:
Not even the developer of the application could tell you what button that xpath refers to, which makes this step quite meaningless as a way of describing behavior.
To tackle this, Iridium introduces the notion of aliases. Aliases are nothing more than key/value pairs, and can be used to hide obtuse values, like the xpath above, behind a user friendly name. This means the step above can be rewritten like this:
Referencing identifiers that mean nothing to human beings through aliases makes the step readable again.
But this solution can be improved on. While the reference to the button might be called “Continue Button, ” the step still talks about xpaths, which again you would not do when describing the behaviour required to access a web application.
The second collection of steps introduced with Iridium moved away from these explicit notions of xpaths, CSS selectors and ID’s with what were called “found by” steps. These steps would attempt to match the element by testing the identifier, or identifier alias, as if it were an xpath, CSS selector, ID attribute, name attribute, value attribute, class, or normalized text content. There are some cases where these identifiers are not distinct (you could have a button with the ID and text content of submit for example) , but in practice these situations were rare.
In this example, we would expect to click a button that has the text content of “Submit.”
This new “found by” style of identifying elements was a big step in the right direction. Although the step above sounds a little robotic if you read it out aloud, it does come close to describing how a person would interact with a web application.
With the latest releases of Iridium there is a third style of step definitions that come very close to describing a test in the way that a person would describe it to another person. In the end, the change was quite a simple one: remove the phrase “element found by, ” and add any description you like after the identifier. For example, the step above can now be written like this:
Although it seems obvious in hindsight, it took a few revisions of Iridium to build a dialect that was both practical and natural. But with these steps in place, it is possible to write complete tests like the one shown below, which was taken from an actual working end-to-end test of an insurance web application.
Even without seeing the web application itself, it is not hard to understand what the test is doing, because the steps describe the actions being taken in a very natural format.
If you are interested in writing end-to-end tests like the one shown above, check out the Iridium documentation page, and take a look at the courses available on Udemy. Iridium itself is a free and open source project on GitHub.
