Why Cucumber?

This is a classical view of how quality is perceived by different roles and why are there gaps. There are other views too, but one very simple view is as below

QualityGaps

There are lots of articles online on how engineering departments constantly try to close these gaps and among many software development methodologies, Agile is definitely the reality these days.

Let’s start with Agile manifesto principles. The four principles are:

  1. Individuals and interactions over processes and tools
  2. Working software over comprehensive documentation
  3. Customer collaboration over contract negotiation
  4. Responding to change over following a plan

As we can see “Collaboration” is a key ingredient while we follow Agile. Extending on the same concept, collaboration coupled with communication is quintessential to have agile software teams work effectively while building the product in terms of small increments.

Continuous Test Automation / Automated Acceptance Tests

While the gaps always exist in terms of what a stakeholder needs vs. what gets delivered, we will need to work on closing the gap as much as possible. One way is for engineering and business teams to collaborate on a common language and have a suite of automated tests that when run, do what the stakeholder wants. These are hence called acceptance tests because the stakeholder find them acceptible.

The automated tests fail at the time of writing because no source code (and hence the AUT) exists, however it brings the stakeholders and developers on the same page about “what” has to be done [Bear in mind that acceptance tests capture the behavior of the application as seen from outside i.e. as a user/stakeholder experiences it. This is different from unit tests, that capture whether you build the thing right, not necessarily build the right thing]

Another important characteristic is that while Automated tests can be written at any phase of time in software development [which has traditionally been thought to be written only for regression], with Continuous Test Automation, we emphasize that automated tests is THE way to do testing and it has to be “continuous“, so that it aligns with the agility and also the fast changes in requirements that are common these days with Digital disrupting every industry.

Hence the following practices came into existence and we already talked about this briefly in our intro session on ATDD/TDD/BDD.

We also talked about Continuous Test Automation patterns extensively in our series on CT patterns.

Common Page [Cucumber’s part]

So getting to a common page on agreeing that the system was built in alignment with the requirements has to be constantly visited and that means we need to have a common language of communication that bridges gaps as much as possible. More so build the system incrementally and each increment should confirm the behavior of the system [as agreed by the stakeholder].

As stated in “The Cucumber Book”…

Cucumber helps facilitate the discovery and use of a ubiquitous language
within the team, by giving the two sides of the linguistic divide a place where
they can meet. Cucumber tests interact directly with the developers’ code,
but they’re written in a medium and language that business stakeholders
can understand. By working together to write these tests—specifying collaboratively—not only do the team members decide what behavior they need to
implement next, but they learn how to describe that behavior in a common
language that everyone understands

As we see, Cucumber is NOT this awesome Automation framework or software solution that does automation or provides all libraries to interact with browser, database, api’s etc.

Cucumber facilitates collaboration and hence a more quality product as a result of better communication and collaboration between various roles in software development life cycle aligning with the business stakeholder.

An Example.

A simple cucumber scenario that describes  a Sign in on a website

As you can see we have described the behavior of the system [for a simple workflow] in a human readable english -ish language, that can be understood by almost anyone on the team. This is what Cucumber lets us do.

Of course you might ask now, can I run this as is. No, we would of course have to write some code behind that can make this example run an automated test that actually does the operations specified. However we have enough tools and software that does these for us right. And we have entire tutorials already written that do this for us in Tutorials menu at the top.

Make the case

So as you can see, given the above context, we have a huge benefit of using Cucumber in the following ways.

  • Common language and hence common page – facilitates collaboration and adaptation to changes
  • Living documentation – Apart from serving as traditional documentation, since they are constantly refactored, they reflect the state of the current system.
  • Executable Specifications – Since they are executable [with step definitions], they close the quality gaps as described at the top of this page
  • Source of truth – If followed religiously in a team by everyone with ATDD process, they can become the source of truth

What if it is NOT english?

Cucumber works in over 40 languages and has been implemented with multiple programming languages like Ruby, Java, C# and so on.

What that means to us is again – even if we were working in an internationalized environment, we have ways to bridge the quality gaps by using Cucumber. Isn’t that great ?