BDD automation: Avoid conditional logic in your test code

if("student".equals(userType)){
   Assert.assertEquals("STUDENT REGISTERED SUCCESSFULLY",actualMsg);
}else{
   Assert.assertEquals("ALUMNI REGISTERED SUCCESSFULLY",actualMsg);
}

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:

Feature: Registration

  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.

public void registration(String firstName,String lastName,String email,String userType){
        String responseMessage=register(firstName,lastName,email,userType);
        if("student".equals(userType)){
            Assert.assertEquals("STUDENT REGISTERED SUCCESSFULLY",responseMessage);
        }else{
            Assert.assertEquals("ALUMNI REGISTERED SUCCESSFULLY",responseMessage);
        }
    }

Issue with conditional logic

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

Conclusion

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.