Some People Hate Cucumber

This may come as a surprise to you, some people actually hate Cucumber.

But, do you know why?

Why Hate Cucumber?

Over the years of trying to encourage poeple to adapt Cucumber, here is a list of the most common ‘reasons’ that I have had in response:

It’s An Overhead

When asking colleges to adopt Cucumber as a tool to help remedy the bridge between BA’s and Developers, “Cucumber is an overhead” was the response I got back.

The first time I came across this response, I was a little confused.

How is Cucumber an overhead?

Overtime I figured out that this was simply a reason not to write scripts and directly write code. For a developer, it is usually enough that the requirements are captured in a task tracking board. Having to write feature files which then call code can seem a little ‘middle man’ redundant.

It makes more sense to write small, quick tests and run them in CI. It can become an overhead to write feature files which call code to run tests.

It’s Not A Testing Framework

Cucumber is not a testing framework, I can write a post on this one statement alone.

In short, Cucumber is certainly not a testing framework. It is a framework which can be used to supplement testing, it is not purpose built for testing. When asking a developer to use a framework for testing, they would expect a testing framework. Cucumber in this instance is not.

At the point of hearing this response, I do wonder the justification of the statement. It does make sense to focus on testing frameworks for testing problems. On the other hand, Cucumber can be used to enhance any framework for testing. It can help to implement BDD, clean reporting and bridge any technical gaps between client and hosts.

Bad Memories

Well, this is an interesting one!

How do you convince someone that a technology, when used correctly, is a good idea. And how do you convince that same person when their past experience with the same technology has not been very good (credit to the previous person who tried to introduce it).

Sadly, I have had the ‘pleasure’ of talking to developers who have had a bad experience with Cucumber in the past. This effectively implanted a negative picture of the software. Luckily, given there is an open mind, it can be easy enough to re-implement or re-try the application. Perhaps turn around the ‘hate Cucumber’ thinking. Alternatively, good luck.

So, What Now?

Well, if your passionate about Cucumber and really want to introduce it into your work place, don’t force it. Never try to force the notion. Instead, try to spike a small project and then demo it. You never know, you may convert someone.

You Don’t Need Cucumber for BDD

You don’t need Cucumber for BDD. Oh boy, I can already sense the loving embrace of you, the reader. Let me start by saying one thing, I absolutely love Cucumber. It is an amazing tool and serves an amazing purpose. Cucumber allows one to easily express the behavior of a system through plain text (expressed in Gherkin), allowing many non technical people to understand what is going on. You can additionally generate reports more easily, create a living, breathing test spec and possibly better a debugging mechanism. But, hold on, do you need Cucumber for BDD?

Cucumber for BDD – What is BDD?

So, what is BDD? BDD is an acronym for ‘Behavior Driven Development’. When writing a test, expressing it in plain English, without exposing any code and trying to describe the condition is BDD. It allows you to ‘describe’ a scenario and represent that in a descriptive file. Let’s have a look at a simple example:

Given I navigate to www.thetestroom.com
When I see the 'Join blog subscription' pop-up
Then I will enter my email address
And I will subscribe
And I will see a notification message

The above is a very simple scenario, captured in simple English. The ‘scenario’ has been written using Gherkin, trying to express a condition (Given), an event (When) and an action (Then). As opposed to TDD (Test Driven Development), BDD does not instruct that we write a failing test first. A BDD test can be written after the main application code has been written.

Cucumber runs test using Feature files which instructs a developer to write scenarios using Gherkin syntax, almost forcing BDD. Each step in the Feature file is then matched to a method in a code file, somewhere. Now, back to the focus of this post. If Gherkin is needed to express scenarios and Cucumber encourages BDD, do we need Cucumber to express a test in BDD?

BDD in a Java Test

Trying to answer ‘do we need Cucumber for BDD’ can be difficult, let’s take a look at a test written in WebDriver, in Java:

public class TheTestRoomTest {
 
    @Test
    public void testChromeSelenium() {
        System.setProperty("webdriver.chrome.driver", "/selenium-driver/chromedriver");
        WebDriver driver = new ChromeDriver();
        driver.get("http://www.thetestroom.com/");
        driver.findElement(By.name('email_field)).sendKeys('my-email-address@domain.com');
        driver.findElement(By.id('subscribe_btn)).click();
        Assert.assertEquals("Thank you for subscribing", driver.findElement(By.className('subscription_notification')).getText());
        driver.close();
    }
}

Let’s break the above test down a little. Firstly, the above test is identical to the Feature file detailed above. We are firstly creating our Driver followed by navigating to www.thetestroom.com. We then subscribe to TheTestRoom and check to see the confirmation message.

Great, so what is the difference between the Java test and the Cucumber Feature file? From a test coverage perspective, nothing. From a technical perspective, yes maybe. For Cucumber, you would need a Feature file, a step definition class. For the Java test above, in its current form, the single script is enough. However, when using Cucumber you gain the advantage of allowing others to reuse the step deifintion methods more easily, you lose this ability with the Java test. Also, the Cucumber Feature file is much easier to read and understand, Java test is not. Wait, perhaps not.

Re-using methods in Java Test

Let’s take another look at our Java test and see if we can do anything to update it, perhaps promote code re-use. What would happen if we extract calls to Driver and move them out? This may help us to make the Java test more easier to read and understand.

public class HomePage {
 
    public WebDriver driver;
 
    public HomePage() {
        System.setProperty("webdriver.chrome.driver", "/selenium-driver/chromedriver");
        driver = new ChromeDriver();
        driver.get("http://www.thetestroom.com/");
    }
 
    public void acceptSubscription(String email) {
        driver.findElement(By.name('email_field)).sendKeys(email);
        driver.findElement(By.id('subscribe_btn)).click();        
    }
 
    public String getNotificationMessage() {
        return driver.findElement(By.className('subscription_notification')).getText();        
    }
}
public class TheTestRoomTest {
 
    @Test
    public void testChromeSelenium() {
        HomePage home = new HomePage();
        driver.acceptSubscription('my-email-address@domain.com');
        Assert.assertEquals("Thank you for subscribing", home.getNotificationMessage());
    }
}

Now that we have moved all the calls to driver to the ‘HomePage’ class, we can now reuse any methods for the driver in any other class. It looks like this approach now solves our ‘re-useable’ code dillema. Wait, let’s quickly revisit the test and make one more small change:

public class TheTestRoomTest {
 
    @Test
    public void testChromeSelenium() {
        // Given
        HomePage home = new HomePage();
 
        // When
        driver.acceptSubscription('my-email-address@domain.com');
 
        // Then
        Assert.assertEquals("Thank you for subscribing", home.getNotificationMessage());
    }
}

Putting the Java test and Cucumber Feature file side by side, you can see that they almost serve the same purpose. Well, it looks like we now have a Java test but in a very BDD fashion.

Do we need Cucumber for BDD?

No, I don’t think so.

Cucumber allows us to really easily and quickly write behaviors for an application. It provides reporting and allows people who don’t write code to write tests. But, take a second to ask yourself, do you really need all that meat. If all your trying to do is implement a BDD strategy, can this be implemented through discipline alone? I don’t think Cucumber should be adopted for the sake of BDD. With a little bit of elbow greese you can easily implement BDD style of tests, this also makes your tests more cleaner, easier to read and more manageable.

So, what do you think? Do we need to use Cucumber for BDD?