Imagine this case: You want to test a workflow that slightly changes if certain pre-conditions are fulfilled. Sounds familiar? I bet it does. It’s a scenario that I actually stumble upon fairly often in my daily work life. So far, there were two ways you could go about testing it:
A: You created the entire workflow two or more times, slightly modeling it each time to handle the small differences.
B: You implemented a conditional solution in code.
Neither of these solutions was ideal. Option A made the test case unnecessarily complicated – and as we all know, was a nightmare to maintain. Option B, which seemed to be the more elegant way to solve this scenario, required programming skills. Additionally, as conditions were not transparent at all in the test suite, you couldn’t see which modules actually contained conditional branches. Lucky for us, things have changed for the better, and your top voted feature request is now available with Ranorex 7.1.
Codeless creation of conditions in Ranorex 7.1
With Ranorex 7.1, you can now easily define conditions in the test suite without coding. This means that you can equip individual test cases and smart folders with conditions that refer to data from data sources or parameters directly in the test suite. Once you’ve set up the condition, your test case or smart folder and its underlying subtree (including test cases, smart folders, module groups as well as recording and code modules) will only be executed if a predefined condition is fulfilled.
Structure of conditions
But what do conditions in Ranorex 7.1 actually look like?
A condition consist of one or more rules. If it contains more than one rule, you can decide if either all or any of the rules must match to fulfill the condition for the test case or smart folder, including its child elements, to run. A checkmark at the end of the rule indicates that the rule has been set up correctly. To add further rules to your condition, you can simply use the Add rule button. To delete a rule, use the minus button. You can deactivate a condition by unchecking the corresponding checkbox.
Hands-on examples of conditions
To get a better idea of the concept, I have prepared a practical example:
Testing a checkout process with different payment methods
Let’s assume you want to test the checkout process of your web store that allows different payment methods, and each method triggers a slightly different workflow.
In Ranorex 7.1, you can now easily use conditions to cover the checkout process for all payment methods in a single test case, instead of having to create a test case for each payment method – without having to dip into code.
To do so, start by creating a smart folder in your test case for each payment method. Each smart folder should contain a module that covers the specific payment steps. Next, you will have to define when each smart folder should run. That’s when we need the conditions. Let’s start defining the conditions:
First, open the conditions tab of a smart folder, by right clicking the desired item in your test suite and select Condition… in the context menu.
Next, you’ll have to set up the condition. As you can see in the screenshot above, this condition is based on a rule, which refers to:
- A Data source – in this case a simple data table, named Payment_Option, and
- its column Payment_Method, whose value has to be equal (IsEqual) to the defined value PayPal.
Modeling this test with only one test case instead of creating a test case for each payment method drastically decreases your maintenance effort and keeps your test suite clear and simple. See the difference for yourself:
Conclusion
Test workflows in your test suite should be kept as simple and clear as possible. Conditions can help you significantly reduce the maintenance effort of your test suite due conditional branching and further improve the robustness of your test scenarios.
With Ranorex 7.1, you can now easily create conditions directly in your test suite with just a few steps. There is no need to implement anything in code and you will now benefit from enhanced transparency in your test suite.
