How effective is cucumber for BDD?

Cucumber and BDD (Behavior Driven Development), are old topics. A lot of information has already been shared about this topic. But I think it’s often the technical aspects that are the most important. I want to approach the topic holistically and not only from a technical perspective.

Cucumber and BDD (Behavior Driven Development), are old topics. A lot of information has already been shared about this topic. But I think it’s often the technical aspects that are the most important. I want to approach the topic holistically and not only from a technical perspective.

Let me start by saying that I love Behavior Driven Development but don’t like the idea of tying it with a specific tool. Cucumber is an example. Let’s first review the main benefits of BDD. BDD is:

• Collaboration for all stakeholders (including non-technical people)
• Clear tests are easy to understand by all stakeholders
• Streamlines Development (tests steps are easy to understand by developers)
• User-focused (to test the behavior and functionality of an application using the user’s perspective, rather than writing technical tests at a low level).

If that is what BDD is all about, then it’s about how you structure and write your tests. It doesn’t matter which tool you use to create them. While stakeholders want to collaborate on the testing, they don’t necessarily want to implement the tests. Regardless of how your test is coded, if it embraces BDD concepts then you will already reap the greatest benefits. Cucumber and other BDD tools may offer additional benefits via GWT nomenclature which easily communicates the conditions, objective, and pass conditions in plain English that is easy to understand by non-technical people. However, not all organizations will reap enough benefit from these tools in order to justify investing in them. BDD can be easily implemented by writing your tests and strategy in a way that is easy to understand and followed by all stakeholders (POs PMs BAs etc.). No matter what format, technique or tool you use for writing your tests, it doesn’t matter. Every test must contain the three essential areas of prerequisites, test-steps and validation (aka Given When, Then in Cucumber). It is valid as long as you clearly describe the test case and highlight these areas.

Let’s look at a simple example to illustrate this. Let’s say you want to write a test for successful login. Write it as follows: “Signing into the staging environment with valid credentials, should take the user the home page.” This test case uses the following terminology: “Staging environment” is the prerequisite. “Signing in using valid credentials” is the When, which is the test steps, and “should take the user the home page”. (aka validation). This test case perfectly embraces the BDD concept, without having to use the GWT nomenclature that Cucumber can understand. Behavior driven tests don’t have to conform to this nomenclature.

We have now established that BDD can easily be adopted by tailoring your tests to the business or user. Let’s now examine the technical reasons why Cucumber is an unnecessary layer. Cucumber is a layer of abstraction that is added to your framework. This is the main argument of automation gurus against it. Let’s explore this argument and see why it is so. As a framework designer, let’s take POM (Page Object Model), as a reference. You would implement the code to operate on the page as an user. In the login test case, you would implement methods such as ‘OpenWebPage, InputUserName, InputPassword, and ‘ClickLoginButton. An assert statement would then be used to validate that the page you landed upon after logging into the system was complete. This abstraction of GWT would allow you to fit the test case into GWT nomenclature. It would require that you place your methods ‘OpenWebPage, ’InputUserName, & ‘InputPassword, and ‘ClickLoginButton,’ and assert those methods. This extra abstraction is not necessary. Why? Why? If your test objective is to verify that public users are able to login using a valid username/password, then the behavior is that once they log in with the correct username/password they will be taken to the dashboard page. In GWT nomenclature, you might write ” Given A public user, After the user has entered the username and password, They will be taken to the dashboard page. Now to suffice for this if you name your test “Public_User_With_Valid_Credentials_Can_Login_To_See_Dashboard” it conveys the same message, and if you are diligent about reporting your test failures such that they clearly communicate the point of failure then you have achieved exactly what is needed from stakeholder’s point of view, without building the extra layers of code to accommodate for GWT nomenclature. This is because non-technical stakeholders won’t want to see the test implementation, but will want to work together on the test case. This is exactly what adds an additional layer to the behavior code.

While I have written many frameworks that adhere to the above philosophy, where all tests are behavior-driven, I never had to adapt them to any tool like Cucumber and SpecFlow. To summarize, Behavior Driven Development is conceptual and high-level philosophy that does not necessarily require any tools. Cucumber, SpecFlow and other tools can be used to implement these philosophies. Although there are many possible implementations of these philosophies, they should be focused on the test design and not worry about the details.