GHERKIN - NHỮNG QUY TẮC ĐỂ VIẾT MỘT FEATURE TỐT

Ngày nay trong các dự án Agile, cách tiếp cận theo BDD đang trở nên phổ biến hơn bao giờ hết thì việc làm thế nào để có thể viết được các file Testcase (*.feature) tốt, chuyên nghiệp giúp tất cả các thành viên (kể cả các thành viên ngoài đội dev) cũng hiểu được đang ngày càng trở nên cần thiết.

Với kinh nghiệm làm việc về Automation Test thời gian dài viết Gherkin, Anh Tester sẽ chia sẻ những kinh nghiệm của mình thông qua bài viết này.

Nguyên tắc chung

BDD/Cucumber không được thiết kế để "hỗ trợ kiểm thử", nó là một công cụ hỗ trợ để phát triển các sản phẩm do đó đầu tiên, hãy xác định đúng sẽ giúp bạn sử dụng đúng.
Một kịch bản (Scenario) nên rõ ràng về một hành vi cá nhân (actor) nào đó mà phần mềm sẽ phục vụ.
Ví dụ: Thay vì viết theo kiểu diễn giải theo từng hành động như sau
```
Given I visit "/login"
When I enter "Bob" in the "user name" field
And I enter "tester" in the "password" field
And I press the "login" button
Then I should see the "welcome" page
```
Thì chỉ cần viết
```
When "Bob" logs in
```
Các file Feature sẽ có thể được đọc bởi bất bất cứ ai, thậm chí là những người không biết về ứng dụng mà chúng ta đang xây dựng.
Mỗi chức năng sẽ nên có một file feature (.feature) riêng biệt.
Gherkin nên được viết theo cách khai báo (declaratively), không theo cách bắt buộc (not imperatively).
Mỗi file Feature phải chứa tối thiểu 1 Scenario và không quá 10 Scenario
Mỗi Scenario không nên có quá 10 Steps.
Chữ cái đầu tiên của tiêu đề Scenario/Feature nên viết hoa, còn lại viết thường
Tất cả các kịch bản (Scenarios) nên được viết theo nghĩa của người thứ ba, KHÔNG viết "I log in.../I visit..." (như đề cập ở ví dụ trên)

Khai báo kịch bản (Scenario) và tiêu đề của kịch bản

Tránh sử dụng các từ như: 'but', 'or', 'like', 'since', 'verify', 'assert', 'should' khi viết nội dung scenario.
Tiêu đề của Scenario nên viết ngắn gọn, khái quát về các hành vi được kiểm thử
Kịch bản cũng nên được viết ngắn gọn rõ ràng

Viết Steps

Các steps trong Given nên được viết ở thì quá khứ, ví dụ: Given An admin user **has** been created.
Các steps trong When nên được viết ở thì hiện tại, ví dụ: When The admin **deletes** a user account.
Các steps trong Then nên được viết ở thì hiện tại, ví dụ: Then The user **is** unable to login.

Examples

[Bad]

Feature: Google searching

Scenario: Google search shows results
   Given the user opens a web browser '<-- Present tense'
     And the user navigates to "https://www.google.com/" '<-- Questionable hard coded test data (throughout)'
    When the user enters "panda" into the search bar '<-- Imperative'
     And the user presses the search button '<-- Imperative'
    Then links related to "panda" are shown on the results page
    When the user clicks on the "Images" link at the top of the results page '<-- Disrespectful of BDD syntax'
    Then images related to "panda" are shown on the results page '<-- Disrespectful of BDD syntax'

[Good]

Feature: Google searching

Scenario: Searching on google returns accurate results
   Given the google search page has been loaded '<-- Past tense'
    When the user performs a search for "panda" '<-- Declarative, present-tense'
    Then the returned results are accurate '<-- Declarative, present-tense, Respectful of the BDD syntax'

Các bạn có thể tham khảo bài BDD là gì để hiểu hơn về Gherkin nhé.

Trên đây là những gì mình rút ra được sau thời gian làm việc với Gherkin, các bạn có thể tham khảo nhé, cảm ơn rất nhiều !!!