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 khi trình bày một Gherkin

 

  • 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​

    Hoặc

    Given user am on the login page
    When user log in
    Then user should see the "welcome" page​

     

  • 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. Chức năng gồm nhiều case test tương ứng nhiều Scenario
  • 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. Tránh dài dòng khó hiểu. Kẻo rơi vào chi tiết hoá dạng step của test case thuần
  • 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

Ví dụ:

Feature: Google Searching
  As a web surfer, I want to search Google, so that I can learn new things.
  
  Background:
    Given a web browser is on the Google page

  Scenario: Simple Google search for pandas
    When the search phrase "panda" is entered
    Then results for "panda" are shown

  Scenario: Simple Google search for elephants
    When the search phrase "elephant" is entered
    Then results for "elephant" are shown​


🔆 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.


🔆 Tags

  • Tags nên được viết ở dạng chữ thường
  • Các từ trong một Tags nên được ngăn cách nhau bởi dấu gạch ngang
  • Tags nên ngắn gọn
  • Ví dụ: @example-tag, @regression, @smoke



🔆 Ví dụ Gherkin tốt

================================

[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​'


================================


[Bad]

Feature: Subscribers see different articles based on their subscription level 

Scenario: Free subscribers see only the free articles
  Given users with a free subscription can access "FreeArticle1" but not "PaidArticle1" 
  When I type "freeFrieda@example.com" in the email field
  And I type "validPassword123" in the password field
  And I press the "Submit" button
  Then I see "FreeArticle1" on the home page
  And I do not see "PaidArticle1" on the home page

Scenario: Subscriber with a paid subscription can access "FreeArticle1" and "PaidArticle1"
  Given I am on the login page
  When I type "paidPattya@example.com" in the email field
  And I type "validPassword123" in the password field
  And I press the "Submit" button
  Then I see "FreeArticle1" and "PaidArticle1" on the home page  

[Good]

Feature: Subscribers see different articles based on their subscription level
 
Scenario: Free subscribers see only the free articles
  Given Free Frieda has a free subscription
  When Free Frieda logs in with her valid credentials
  Then she sees a Free article

Scenario: Subscriber with a paid subscription can access both free and paid articles
  Given Paid Patty has a basic-level paid subscription
  When Paid Patty logs in with her valid credentials
  Then she sees a Free article and a Paid article
  • Anh Tester

    Đường dẫu khó chân vẫn cần bước đi
    Đời dẫu khổ tâm vẫn cần nghĩ thấu