Author: Mao TAKAHASHI
Published in: May 25, 2023
Have you heard of BDD (Behavior-Driven Development) before? I had heard of it before, but I couldn't imagine how to write test cases in practice.
I think I finally understand BDD test cases by actually writing Feature files and implementing automated tests.
I will write about the process I went through to be able to write BDD test cases in Gherkin format Feature files, although it is not yet "perfect".
If you want to see various examples of Feature files, please check 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, but I won't focus on that here.
Test cases are written in natural language and shared among various roles such as developers and testers. Also, the Feature file is a file containing test cases and is written in Gherkin format.
Furthermore, by using Feature files and frameworks such as Cucumber, they are also used for test automation.
The definition of BDD is often expressed as above. However, I think there are few people who can write Feature files smoothly just by looking at this.
From here, I will enter the process I actually learned.
Understanding how to write Gherkin
First, in order to write Feature files, you need to understand Gherkin. I have used Cucumber and Java for implementing automated tests before, and I read this site.
You can understand the contents of writing test data and test cases themselves in natural language, and the use of data-driven tests by using Given, When, Then, and And.
Writing a Feature File
Next, I will write a Feature file referring to Gherkin's format and some examples. For the ease of understanding, I will use the example of a test of a purchase on an E-commerce site.
Feature: E-commerce Site Test
Scenario: Purchase a product
Given open the E-commerce site's top page
And click the login button
And enter the user name
And enter the password
When click the login button
Then the 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
Although those who understand BDD well may know it at a glance, this is typical of bad writing. So, what is bad? I will explain the three improvement points.
Improvement point 1: Make the purpose of the test case clear
As for the person who created this Feature file, he or she may have thought about what kind of test he or she wanted to do while creating it. However, it is not clear what one is testing when others look at it.
Do you want to check "can log in" or "can search"? Or do you want to "purchase a product"? Although "purchase a product" is written in the Scenario, various elements are mixed in the test case, making it difficult to understand what you want to test.
As mentioned in the "What is BDD?" section, Feature files are shared among various roles such as developers and testers. Therefore, everyone must understand what is being tested.
Improvement point 2: Make the checkpoint (Then) one
As a factor why the purpose of the test case is not clear, there are also multiple checkpoints. If you want to test "purchased a product", Then must be one place such as "the product is purchased".
So how should we describe the login and product search that is before the purchase of a product? I will include an example of the modified version at the end of this article, so please stay with me a little longer until the end.
Improvement point 3: Do not write operation procedures in Given, When, Then, And
The contents of Given, When, Then, and And are written as operation procedures. Remember that the contents of BDD test cases are behavioral, not specific operation procedures.
If you remember it, you will be able to grasp the image, but I myself could not understand what "behavior" meant just by hearing the word. (If you are good at English, can you understand it just by hearing "Behavior"? At least it was difficult for me to understand just by hearing "振る舞い" in Japanese...).
Furthermore, if you write in a way that focuses on behavior rather than operation procedures, the test case itself will become much easier to understand.!
Improved Feature file
Below is an example that incorporates improvement points.
Feature: E-commerce Site Purchase Function
Scenario: Users registered in E-commerce site purchase one searched product
Given that the user has logged in to the E-commerce site
When purchasing 1 searched "dress" product
Then the product is ordered
With only 3 lines of Given, When, and Then, we were able to show a test case that was so long! I think you can instantly tell what you want to test.
In general, Given, When, Then are said to describe the following contents.
- Given
- Before the behavior is executed, the state or preconditions.
- When
- The behavior itself.
- Then
- The result of executing the behavior.
Although the word "definition" may sound difficult, it may be easier to grasp if you think in terms of "Given: under what circumstances," "When: what if you do," and "Then: what will happen".
Let me explain the previous question.
So how should we describe the login and product search that is before the purchase of a product?
Here, "login" refers to the user's state and can be considered a condition for purchasing a product. If you also want to test purchasing without logging in, write it as a separate scenario.
Regarding "product search", I described it in the "When" section to include the meaning of what kind of product to purchase. However, if there is no special reason for the name or number of products, the following may be listed.
Feature: Purchase function of E-commerce site
Scenario: Users registered with the E-commerce site will purchase the searched product
Given that they are logged into the E-commerce site
When they purchase the searched product
Then the product is ordered
For specific data such as product names and quantities, it is often better to use Gherkin's "Example" or "Data Table", so use them as needed.
Conclusion
This time, I explained how to write BDD feature files. I am still groping around, so if you have any opinions on what should be done better, please give me feedback.
We provide various example test cases as a content service called "Reka".
If you want to see example test cases such as feature files and Excel files, please use them! (We will continue to add test cases as needed) We also welcome feedback on Reka.
