When you have test code written like that given above—or. in other words, the code is written to assert an outcome based on conditional logic—it won’t test the scenario as it should.
When writing test automation code for behavior-driven development (BDD) scenarios (or for that matter any test automation code), it is important to make sure the code doesn’t assert/validate an outcome based on a condition. Testing for multiple test outcomes based on some condition means that you can never tell if the test has worked exactly as intended. If the test you wrote doesn’t verify the test you intend to verify, then you and other stakeholders won’t have the confidence in your BDD automation suite.
When you write scenarios in BDD, they need to be deterministic. In other words, the scenario must test only one outcome. Deriving deterministic scenarios during the scenario discovery phase is critical. Using techniques like OOPSI helps in deriving scenarios that not only provide maximum business outcome but are also valid. With OOPSI, you can also avoid issues like the one I mention above. A test that uses branches (e.g., “if” conditions) or loops can have different outcomes. As a result, you will end up with different results each time.
In this article, we’ll look at using conditional logic in a test automation suite. We’ll also delve into the issues accompanying this type of test code and the ways to address them.
What is conditional test logic?
Conditional test logic is code that uses some kind of condition to validate the test. Let’s take a simple scenario. The goal of this scenario is to check whether a user successfully registers in a portal. A sample scenario is given below:
Scenario: Check User has registered successfully
Given User doesn’t exist
When user registers in the student-alumni registration portal
Then success message should be shown successfully
For the “Then” step in the scenario above, the step definition would be something like the one that follows below. The goal of the following test code is to determine whether the user registration has gone through successfully for a student or for the alumni, depending on the type of user.
When you have test code like the above, which uses a condition to assert an outcome, you can never be sure which part of the code executes successfully. Has the SUT registered “student” or “alumni” successfully? What happens if the SUT always returns a message as “student registered successfully”, even if “alumni” registers? In this case, your test would always pass and would never pick up that bug. This is a code smell and should be avoided at all costs.
Avoiding conditional test logic in your BDD test suite
Keeping the test code simple and always writing it to test one thing only is the way to avoid conditional logic in your test code. If we take the above example, you could split the scenarios to check each of the user types separately in different scenarios, as you can see below. This way, your code doesn’t need conditional logic, and each scenario is deterministic.
As you can see from the above, you have two scenarios: each does only one thing, and both are deterministic. Therefore, when you run these scenarios you can be certain that they check for both student and alumni inputs. If the SUT always returns the message “Student registered successfully”, even for the Alumni user type, then scenario 2 would always fail.
Different types of conditional test logic
Several types of conditional logic are similar to the one I cover in this article. Most if not all of these could be a code smell in your test code, so they should be analyzed and avoided:
In your “then” step (as above)
To initialize the test data in your given step
When calling different parts of the SUT in your “when”step
Using loops to check certain contents of the collections
As you can see, avoiding conditional test code in your BDD test suite is essential to create a suite that captures critical bugs in your SUT and improves maintenance. This is one of the main reasons we chose not to provide an option for users to use conditional statement in NoCodeBDD.
We built NoCodeBDD based on years of our learning and understanding complex test automation suites, and we understand what works and what doesn’t. The lessons that we learned over the years are baked into NoCodeBDD, so our customers don’t have to make those expensive mistakes we made when we were our own building test automation suite. NoCodeBDD’s basic version is free: download it at https://www.nocodebdd.com/download.
With NoCodeBDD, teams can automate Behavior-Driven Development (BDD) Scenarios for mobile applications with few clicks. To create test automation for mobile scenarios, typically, one would use Appium. Using NoCodeBDD, all you have to do is: Following gif shows how this is done for a sample mobile application: NoCodeBDD Mobile Automation NoCodeBDD […]
There is a general mis-conception that BDD should be used for testing. Many projects consider using BDD during “Testing phase” and only the QA team uses BDD. When BDD is rolled out this way, the teams don’t see the benefits. In this short video, I have explained how Behavior Driven […]
Running features in behavior driven development (BDD) automation test suite in parallel is fairly straightforward. With NoCodeBDD, running features in parallel is a default option and can be switched between serial and parallel run through click of a button, as shown below: Enabling BDD to run in parallel is the […]