Cucumber for BDD—How Effective Is It?

Whether to use Cucumber and BDD (Behavior Driven Development) is an old topic and a lot has been shared regarding this already. However I believe many times it’s just the high level technical reasons that make it to the forefront of the argument on how effective it is, and I want to address the topic from a holistic point of view and not just technical.

I would like to start with the statement that while I absolutely love Behavior Driven Development, I do not like tying it to any specific tool - Cucumber in this case. Let’s quickly refresh the main benefits of using BDD first. BDD is:

• Collaborative for all stakeholders, including non technical people (all stakeholders use the same terminology)
• Clear (tests are easily understood by all stakeholders)
• Streamlines Development (test steps are easily understood by developers)
• User Focused (so you write tests that test the behavior of application from user’s point of view as opposed to only writing low level, technically-focused tests)

Now if that is the essence of BDD then to me it’s more about how you structure, write, and place your tests, rather than about what tool you use to write them. Stakeholders always want to be collaborative on your tests, but not necessarily the implementation of the tests. If your test embraces the concepts of BDD then you have already achieved the most significant benefits of it regardless of how you code that test. While Cucumber and other BDD tools can provide additional benefits, via GWT nomenclature as it easily communicates the conditions, test objective and pass conditions in plain English which is easily understood by all non technical people, not all organizations will realize enough benefit from these tools to make investing in them worthwhile. Hence, BDD is a concept that can easily be implemented by crafting your tests and test strategy to be such that it is easily understood and followed by the stakeholders (POs, PMs, BAs etc.) regardless of what format, technique, or tool you use to write your tests. Each test always has the three vital areas: prerequisites, test-steps, and validation (aka Given, When, Then (GWT) in Cucumber). As long as the test case is written clearly, highlighting these three areas, regardless whether you explicitly use the GWT nomenclature, it is a valid BDD test.

Let’s understand this with a small example. Suppose you are writing a test for a successful login, and word it as “Signing in with valid credentials in the staging environment, should take the user to the home page.”. In this test case, ‘staging environment’ is the Given aka prerequisite, ‘Signing in with valid credentials’ is the When aka test steps and ‘should take the user to the home page’ is the Then aka validation. It is a test case that perfectly embraces the BDD concept without using the GWT nomenclature which a tool like Cucumber understands. Hence you do not have to bind your tests to that nomenclature for them to be behavior driven.

Now that we have established that BDD can be embraced by crafting your tests to be business or user focused, let’s look at the technical reasons of why Cucumber is just an unnecessary extra layer. The main argument most automation gurus present against Cucumber is “that it’s an extra layer of abstraction on top of your framework”, let’s expand that argument to understand why it is an extra abstraction. In any framework design, for example let’s pick POM (Page Object Model) as a reference, you would be implementing the code for operating on the page as an end user. In our login test case example you would implement methods like ‘OpenWebPage’, ‘InputUserName’, ‘InputPassword’ and ‘ClickLoginButton’ and there would be an assert statement for validating if the page you landed on after logging in was the home page as documented in the test case. To fit this test case into a GWT nomenclature you would be forced to implement this abstraction of GWT, which would mean in one way or the other placing your methods ‘OpenWebPage’, ‘InputUserName’, ‘InputPassword’, and ‘ClickLoginButton’, and assert into those abstractions. This is the extra abstraction that need not be implemented at all. Why? Because as mentioned earlier you had already achieved your test to be behavior driven via your test case design and now to let that concept flow into the implementation of the test or how you code that specific test is just a waste of time. For example if your test objective is to test if public users can login with a valid username and password, then the behavior here is that once a user logs in with valid username and password they should see the dashboard. Now in GWT nomenclature you would write something like “Given a public user, When the user inputs the correct username and password and clicks the Login button, Then they are 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. Again, this is because your non-technical stakeholders will never want to read the implementation of your test but would always want to collaborate on the underlying test case that the code implements. That is precisely what makes that an extra layer of abstraction on coding for the behavior.

I have written a lot of frameworks that embrace the above philosophy and where the tests are all behavior driven but never had the need to adapt to any tool like Cucumber or SpecFlow. Hence to summarize my thoughts I would say Behavior Driven Development is very conceptual and a high level philosophy and does not have to necessarily rely on any tooling. Cucumber and SpecFlow are tools that suggest just one way of implementing those philosophies. There are many ways those philosophies can be implemented but they should focus on the test design while being agnostic of the implementation details.