LET’S GO WITH CUCUMBER! (Part 1)

For those of you who do not know about Cucumber as a testing tool, the title may have sounded a little weird at first glance. Yes, it is a weird name! But we’ll come to that later…

Our squad is responsible for Microservices that are written in Golang (GO). As the Test Automation Engineer of our squad, it is my responsibility to rewrite tests utilizing GO. Since I am a Java person, the idea wasn’t all that appealing at first, but I know GO is a very powerful language that gets more popular each and every day. It is relatively easy to learn and read, offers high performance, and definitely fun to work with. On top of all that, the added benefit is that our automation tests and product will have the same language. These are all really compelling reasons to rewrite tests. So, I started to learn to GO!

Before we cover GO, I want to first cover Cucumber:

Ok, not that Cucumber :)

Cucumber is a BDD testing tool.

We know that every good idea comes out of a problem.

‘Misunderstanding’ is a big problem in the programming world. Business gives the idea, Developers implement the idea, and Testers test if the idea works as expected. This is a simple cycle. The point is, they should all be on the same page, but this is not always the case.

The solution?

BDD (Behaviour-driven development):

Let’s write a user story:

As a user, I want to filter my search results according to price, so that I can find affordable ones.

And let’s write some steps for this story. But this time, write them by using Gherkin Language in a feature file:

We have a user whose name is Leo:

These steps are written as plain text in a feature file. This will help every team member to understand all acceptance criteria. So, this is our ‘readability’

Now, as a QA, I need to implement some code for testing them.

At this point, we have this question: ‘I would like to have functions for these steps and it would be great if there is a naming convention’.

Let’s run this feature file, and this is the output :

There they are! Now we have functions named with our steps in the feature file. We can start implementing these functions. And if we need the same step for a different user story, it will not generate a function for us. It will just find the existing one and will run it.

So this is our ‘reusability’

It’s very good so far, but testers always want more, right? :)

Here comes the new question:

‘What if I need some parameters in my functions? For example, what if I need “price” to be passed as an argument in my function?’

Just parametrize the value by using “ ” in the feature file:

And your functions will pass the “price” as an argument.

The new generated functions with parameters:

This is the ‘dynamism’.

Not done with questions!

Here comes the new one:

‘As a tester, I want to test multiple scenarios for one step. Does Cucumber have an answer for this question?’

Sure it has!

And the answer is Scenario Outline:

It will run my tests for all the data that I put in the Examples part. We have a header row in the Examples part because it needs to be compiled by matching headers with the placeholders in steps.

These are the generated functions:

It looks nice, but of course, I have one more question. With the scenario outline, all the steps are running again and again for each line in the Examples part. However, what if I need to test multiple data for only one step. For example, I want to test only the price filter but for multiple users. For this question, Cucumber’s answer is ‘Data Tables’.

This is from the feature file:

In this scenario, it will transfer the multiple data only for the steps which have the data table, so no need to run all steps for each data.

And these are the generated functions for the steps that I used in the Data Table:

As you can see, now we have a function that passes a parameter that has *godog.Table as a type. Now you can use any collection in your function by reading the data from this feature file.

What is the difference between Scenario Outline and Data Table?

At this point, you may have a question about the difference between Scenario Outline and the Data Table. They are both for passing the multiple data from feature file but the difference is:

• In Scenario Outline, the test runs all the steps for each line in the Examples part (excluding the header line)
• In the Data Table, all multiple data will be passed only for one step which you attached to the Data Table.

In our example:

It will compile the step by passing all these three users together, then it will continue with the next step.

Which one to choose?

If you need to run an entire scenario with multiple data, it is good to choose Scenario Outline.

If you need multiple data for only one step, no need to run the entire scenario for this particular step. Instead, send the multiple data for only this step by using a Data Table.

To sum up, we saw that Cucumber uses Gherkin language that helps business people to be involved in the test scenarios. It is easy to manage, allows us to reuse the code, and focuses on a user perspective. It also has some features such as tags, reports. But these are not the topic of this post.

And why name a testing tool as ‘Cucumber’? The founder of Cucumber, Aslak Hellesøy, called his tool ‘Stories’ at the beginning, but he just wanted to rename it to something a little more interesting. He asked his fiancee for a strange name and she came up with the name ‘Cucumber’. Not sure why not Watermelon or Tomato… But it’s a pretty attractive name!

This was the first part of the Cucumber & Golang in API Testing post. I will write about the Golang part in the next post — stay tuned!