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.
I had the pleasure of hosting a webinar with two industry experts, Rebecca Stone from IBM. During the webinar, Rebecca shared her experience in successfully implementing BDD in a large government project, highlighting the benefits of BDD, why and how she used OOPSI and its role in overcoming challenges faced […]
Rolling out BDD in a project requires careful planning and a well-structured process. As a tech consultant on a large project, I had to make several changes to their BDD process and automation suite implementation. Some changes were straightforward, while others proved more challenging. If you’re considering implementing BDD in […]
10 Tips for Writing Effective BDD Scenarios When rolling out BDD having a clear and concise scenario writing is a vital aspect of successful BDD adoption. This blog post will provide you with 10 tips to enhance your BDD scenario writing, making it easy to understand, maintainable, and efficient. 1. […]
It will be difficult to automate testing if you don’t consider it when creating your web application. It will be difficult, regardless of whether you are a code wizard or a no-code ninja. Here are some crucial ideas to have in mind as you develop your app to make testing a […]