With a few more projects under my belt, it is time to revisit my previous Cucumber blog post. For those who have missed the previous post, link is down below.

The Cucumber plan

One of the main disillusions about this tool is the believe that it is exclusively for testing. And while this is blatantly untrue, during most projects this is exactly how it is being used. As something only testers should be concerned with. It is only in rare cases that analysts and business owners seems to show any interest in writing or even knowing the gherkin test scenario's.

So how should it be used? In order to facilitate Behaviour Driver Development the Gherkin language was created. And that is the main purpose of cucumber, to facilitate communication between everyone in the team.

During the design phase of the application, analysts, developers, testers and project owners should be encouraged to use Cucumber or more specifically Gherkin during meetings and in any documentation. That way, everyone uses the same language. This would facilitate developing the right functionality for the application. Which is undoubtedly the biggest concern we should have during the whole process.

I would still advise the resident tester to take the lead in writing the scenario's.

Usage

Let us be frank, cucumber is quite a powerful tool when used as such. It might not be the intended use, but regardless it comes in handy. Enough chitchat, an example is required.

 Scenario Outline: Calculation
    When I add <numberOne> with <numberTwo>
    Then I get a valid resultmessage: <result>

    Examples:
      | numberOne | numberTwo | result |
      | 1         | 1         | 2      |
      | 25        | 25        | 2      |

So in this example, the scenario is executed twice, once for each row in the table. This way, it becomes easy to add another test case.

Another possible example would be to simply pass the full table into a step definition.

  Scenario: Change the configuration parameters
    When I add the following codes:
      | id | code |
      | 1  | 1    |
      | 2  | 2    |
    Then I fetch the codes from the database  

In this example, it is up to the code behind the stepdefinition to handle the data table. This way you can create fairly complex objects in your testing framework without having to create convoluted functions to handle data.

For me, cucumber becomes a way to escape having to manage resource files, a way to dodge the csv hell that some testers have to deal with.

And yet, sometimes I'm left with no other choice but to do this:

 Scenario Outline: More complex calculation
    When I send the <file> for the calculation
    Then I get a valid resultmessage: <result>

    Examples:
      | file                    | result            |
      | Calculation.txt         | calculationResult |
      | InvalidCalculation.txt  | invalidData       |

Opinion

While I realise that this is not the intended use of cucumber and by extension gherkin, I have to admit that I don't care. This way of using cucumber transforms an inconvenient tool into a powerful, handy weapon in my arsenal of testing.

Cucumber as a communication tool or as a tool to facilitate anything inside the development team for me is a marvellous idea. And that is exactly where it ends, as a thought experiment. Gregory, our residential BDD expert, has quite a different notion about it all.

Links

Previous Cucumber Blog

Cucumber HomePage