Author: Mao TAKAHASHI
Published: May 25, 2023
Have you heard of BDD (Behavior-Driven Development) before? I have, but at first I couldn't imagine how to write test cases using it.
I finally understand BDD test cases after I actually write feature files and implement automated tests.
Even though it is not yet "perfect", I would like to share about how I was able to write BDD test cases in Gherkin format feature files.
If you want to see various examples of feature files, please check out our service “Reka”!
What is BDD?
BDD is a method of software development that focuses on clarifying business requirements. There are often articles that compare it to TDD (Test-Driven Development), but I won't focus on that here.
Test cases are written in natural language and shared among various roles such as developers, testers, and etc. A feature file is a file that contains test cases written in Gherkin format.
Furthermore, by using these feature files together with frameworks such as Cucumber, automation testing also can be realized.
By only reading the information above, how many people can actually write the feature files easily?
From here, I will share the process that I actually learned.
Understand how to write in Gherkin
In order to write feature files, you need to understand Gherkin first. I have read this website multiple times because
I have experience using Cucumber and Java to implement automated testing.
Gherkin Reference - Cucumber Documentation
You can understand that Given, When, Then, And were used, and also that data-driven tests or test data can be written in the feature files.
Write a feature file
Next, by referring to a few examples I will write a feature file in Gherkin.
To male it easy to understand, I will use an E-Commerce website purchase test as an example.
Feature: E-commerce website test
Scenario: Purchase a product
Given open E-commerce website top page
And click the login button
And enter the user name
And enter the password
When click the login button
Then My page is displayed
Given click the search button
And enter "dress" in the search box
When click the search button
Then "dress" is displayed
And the number of search results is displayed
And the price is displayed
Given click the first product
And click the cart button
And select the quantity
When click the purchase button
Then the product is purchased
For those who understand BDD knew, at a glance, that this is typical bad writing style. Why is it bad? I will explain in 3 points on why and how to improve it.
Improvement Point 1: Make a clear purpose for the test case
The person who writes this feature file might be thinking on how they want to test while writing it. However, it is not clear to other people on "what is" to be tested.
Is it to check whether "can log in" or "can search"? Or do they want to check whether they "can purchase a product"? Although "purchase a product" is stated in Scenario, various elements are mixed in the test case, making it difficult to understand what they really want to test.
As mentioned above in the "What is BDD?" section, this feature files will be shared among various roles such as developers, testers, and etc. Therefore, it must be clear to everyone on "what is" to be tested.
Improvement Point 2: Make only one checkpoint (Then)
One of the factors why the purpose of this test case is not clear is because there are multiple checkpoints. If you want to test "purchased a product", only one "Then" with the value of "the product is purchased" should exist.
So, how should we write the login or the product search before the "purchase a product" checkpoint? I will share the modified feature file example at the end of this article, so please keep reading until the end.
Improvement Point 3: Do not write operation procedures in Given, When, Then, And
When we look back at the feature file above, an operation procedure is written in Given, When, Then and And. Remember that the contents of BDD test cases are behavioral, not specific operation procedures.
Once we remember it, we will be able to grasp the overall image, but for myself I could not understand what "behavior" meant. (If you are good at English, can you understand what "Behavior" means in this context? It was difficult for me to understand the context by the word "振る舞い(furumai)" in Japanese...).
Furthermore, if we focus on behavior rather than operation procedures in our writing, the test case itself will be more concise. This will make the test case easier to understand!
Modified Feature file
Below is the modified example that incorporates all the improvement points.
Feature: E-commerce website purchase function
Scenario: Registered user of e-commerce website purcashing 1 serches item
Given registered user is logged in to the e-commerce website
When purchasing 1 searched "dress" product
Then the product is purchased
We were able to indicate the long test case with only 3 lines of Given, When, and Then. I think anyone can instantly understand what needs to be tested here.
In general, Given, When and Then are used for the following contents.
- Given
- Describes the state or prerequisites before the behavior execution
- When
- Describes the behavior itself
- Then
- Describe a result of the behavior execution
It may sound difficult when the word "definition" is used, but it may be easier to grasp if you think of it as "Given: under certain circumstances," "When: if you do something" and "Then: what will happen".
Let me explain the answer for the previous question.
So how should we describe the login and product search that is before the purchase of a product?
The "login" here refers to the user's state, a prerequisite before purchasing a product. If you also want to test purchasing without logging in, write a separate Scenario for it.
For the "product search", I use "When" to include what kind of product to be purchased. However, in the previous test case I wrote it because I thought a specific operation was needed. If there is no special need to mention the name or the quantity of product, we can also write the test case as below.
Feature: Purchase function of e-commerce website
Scenario: Registered user of E-commerce website purcashing searched item
Given registered user is logged in to the e-commerce website
When purchasing searched product
Then the product is purchased
For specific data such as product name and quantity, it is often better to use Gherkin's "Example" or "Data Table". So let's use it accordingly.
Conclusion
In this article, I explained how to write BDD feature files. I am still groping around, so if you have any idea or opinions on what should be done better, please do give me feedback.
Our content service known as "Reka" provides various examples of test cases.
Utilize our contents service "Reka" - to search for example test cases such as feature files or Excel files that meet your needs (We will continuously add new contents). We welcome feedback and suggestions for improvements to our service "Reka".
