CUCUMBER TESTING

TDD

Có yêu cầu -> chạy test ->lỗi -> phân tích lỗi -> fix lỗi -> chạy test

BDD
GHERKIN
Sử dụng tidy gherkin

I. Gherkin là gì?
Gherkin là một bộ quy tắc ngữ pháp tạo nên những văn bản có cấu trúc
đơn giản đủ để Cucumber có thể hiểu.

Gherkin phục vụ nhiều mục đích:

 Đặc tả được thực thi rõ ràng

 Kiểm thử tự động bằng Cucumber
 Miêu tả việc hệ thống thực sự họat động như thế nào

Gherkin sử dụng một bộ các từ khóa đặc biệt để đưa ra cấu trúc và ý nghĩa
cho các thông số kỹ thuật thực thi. Mỗi từ khóa được dịch sang nhiều ngôn
ngữ nói khác nhau.

Hầu hết các dòng trong tài liệu Gherkin đều bắt đầu bằng một trong các từ
khóa. Dòng bình luận được cho phép bất cứ nơi nào trong tập tin. Chúng
bắt đầu bằng 0 hoặc nhiều khoảng trắng, theo sau là dấu thăng (#) và một
số văn bản. Bình luận phải bắt đầu trên một dòng mới. Space hoặc tab có
thể được sử dụng để thụt lề. Mức thụt đầu dòng được đề nghị là hai space.
Đây là một ví dụ về Gherkin:

✅ Cú pháp của Gherkin

Gherkin là ngôn ngữ hướng dòng giống như YAML và Python. Mỗi dòng được
gọi là bước và bắt đầu với từ khóa và kết thúc của các thiết bị đầu cuối với một
điểm dừng. Tab hoặc space được sử dụng để thụt lề.
Trong kịch bản này, một nhận xét có thể được thêm vào bất cứ nơi nào bạn
muốn, nhưng nó nên bắt đầu bằng dấu #. Nó đọc từng dòng sau khi loại bỏ các
từ khóa của Ghrekin như given, when, then, v.v..

🔆 Cú pháp của Gherkin cơ bản có dạng:

Feature: Title of the Scenario

Given [Preconditions or Initial Context]
 When [Event or Trigger]
Then [Expected output]
Một Gherkin có phần mở rộng .feature và chỉ đơn giản là một tệp thử nghiệm
trong khung Cucumber. Khung Cucumber sẽ đọc tài liệu Gherkin và thực hiện
một bài kiểm tra để xác nhận rằng phần mềm hoạt động theo cú pháp Gherkin
đó.

II. Các từ khóa sử dụng trong Gherkin

Mỗi dòng mà không phải là một dòng trống đều phải bắt đầu bằng từ khóa
Gherkin, theo sau là bất kỳ văn bản nào bạn muốn.

Các từ khóa chính là:

1. Feature
2. Rule (as of Gherkin 6)
3. Example (or Scenario)
4. Given, When, Then, And, But (steps)
5. Background
6. Scenario Outline (or Scenario Template)
7. Examples

Các từ khóa phụ như sau:

1. """ (Doc Strings)

2. | (Data Tables)
3. @ (Tags)
4. #(Comments)
Feature (Mô tả chức năng)
Tệp phải có extension .feature và mỗi tệp tính năng chỉ nên có một tính năng.
Từ khóa tính năng có trong Tính năng: và sau lần thêm đó, một khoảng trắng và
tên của tính năng sẽ được viết.

Mục đích của từ khóa Feature là cung cấp mô tả chung về tính năng phần mềm
và nhóm các tình huống liên quan.

Từ khóa chính đầu tiên trong tài liệu Gherkin luôn là Feature, theo sau bởi dấu
":" và một phần ngắn mô tả tính năng này.

Các dòng mô tả này được Cucumber bỏ qua khi chạy, nhưng có sẵn để báo cáo
(mặc định chúng được bao gồm trong các báo cáo dạng html).

Tên và phần mô tả không có ý nghĩa đặc biệt đối với Cucumber. Mục đích của
chúng là cung cấp một nơi để bạn ghi lại các khía cạnh quan trọng của tính
năng, chẳng hạn như giải thích ngắn gọn và liệt kê ra các logic nghiệp vụ (tiêu
chí chấp nhận chung).

Phần mô tả không có quy tắc định dạng của Feature kết thúc khi bắt đầu một
dòng mới với từ khóa Rule, Example hoặc Scenario Outline.

Bạn có thể đặt các thẻ ở trên Feature để nhóm các tính năng liên quan, độc lập
với cấu trúc tệp và thư mục của bạn.

Note : Description

Phần mô tả (giống như miêu tả bên trên cho Feature) có thể đặt bên dưới
Example/Scenario, Background, Scenario Outline and Rule. Bạn có thể viết bất
cứ thứ gì bạn muộn nhưng miễn là không được bắt đầu bằng một từ khóa.

Rule (Quy tắc)

Từ khóa Rule (không bắt buộc) đã được thêm vào trong Gherkin v6. (Lưu ý
rằng Gherkin 6 chưa được tích hợp vào tất cả việc triển khai Cucumber). Mục
đích của từ khóa Rule là đại diện cho một quy tắc nghiệp vụ cần được thực hiện.
Nó cung cấp thông tin bổ sung cho một tính năng. Một Rule được sử dụng để
nhóm lại một số tình huống thuộc về quy tắc nghiệp vụ này. Một Rule nên chứa
một hoặc nhiều kịch bản minh họa quy tắc cụ thể. Một Rule không thể chứa một
Background.

Ví dụ:

Background (Kịch bản chạy trước Scenario)

Từ khóa Background giúp bạn thêm một số bối cảnh vào kịch bản. Nó có thể
chứa một số bước của kịch bản, nhưng sự khác biệt duy nhất là nó nên được
chạy trước mỗi kịch bản.

Thỉnh thoảng, bạn sẽ thấy mình lặp lại các bước tương tự trong tất cả các tình
huống trong một tính năng.

Vì nó được lặp lại trong mọi kịch bản, đây là một dấu hiệu cho thấy các bước đó
không cần thiết để mô tả các kịch bản; chúng là chi tiết ngẫu nhiên Theo nghĩa
đen, bạn có thể di chuyển các bước đã cho như vậy sang Background, bằng cách
nhóm chúng dưới phần Background.
Background cho phép bạn thêm một số ngữ cảnh vào các tình huống trong
Feature. Nó có thể chứa một hoặc nhiều bước nhất định.

Một Background được chạy trước mỗi kịch bản, nhưng sau bất kỳ Before hooks
nào. Trong tệp tính năng của bạn, đặt Background trước Scenario đầu tiên.

Bạn chỉ có thể có một bộ các bước Background cho mỗi tính năng. Nếu bạn cần
các bước Background khác nhau cho các kịch bản khác nhau, bạn sẽ cần chia
chúng thành các feature file khác nhau.

Ví dụ

Note: Các mẹo khi sử dụng Background

Không sử dụng Bối cảnh để thiết lập các trạng thái phức tạp, trừ khi trạng thái
đó thực sự là điều khách hàng cần biết.
Giữ phần background của bạn ngắn. Khách hàng cần thực sự ghi nhớ công cụ
này khi đọc các kịch bản. Nếu Background dài hơn 4 dòng, hãy xem xét chuyển
một số chi tiết không liên quan sang các bước cấp cao hơn.
Làm cho phần Background của bạn sống động. Sử dụng tên đầy màu sắc, và cố
gắng kể một câu chuyện. Bộ não con người theo dõi các câu chuyện tốt hơn
nhiều so với việc theo dõi các tên như "Người dùng A", "Người dùng B",
"Trang web 1", v.v.
Giữ kịch bản của bạn ngắn, và không có quá nhiều.

Step
Mỗi bước sẽ bắt đầu với từ khóa Given, When, Then, And, hoặc But.

Cucumber thực hiện từng bước trong một kịch bản một lần, theo trình tự mà bạn
đã viết chúng. Khi Cucumber cố gắng thực hiện một bước, nó sẽ tìm một bước
định nghĩa phù hợp để thực thi.

Từ khóa không được tính đến khi tìm định nghĩa bước. Điều này có nghĩa là bạn
không thể có một bước Given, When, Then, hoặc But với cùng một văn bản như
một bước khác.

Ví dụ Cucumber xem xét các bước sau là trùng lặp:

Điều này có vẻ như là một hạn chế, nhưng nó buộc bạn phải đưa ra một ngôn
ngữ miền ít mơ hồ hơn, rõ ràng hơn:

Scenario (Ngữ cảnh/ kịch bản kiểm thử)

Mỗi tệp tính năng có thể có nhiều kịch bản và mỗi kịch bản bắt đầu
bằng Scenario: theo sau là tên kịch bản.
Một Scenario là một kịch bản chứa nhiều bước (steps) mô tả các bước hoạt động
một phần chức năng của phần mềm. Trong một Scenario có thể chứa nhiều
steps. Một Sceario thường được mô tả theo mấu:
o Mô tả điều kiện đã có sẵn (Given steps)
 o Mô tả hành động của tác nhân (When steps)
o Mô tả kết quả mong đợi sau hành động (Then steps)

Given (Mô tả trạng thái chức năng )

Khi Cucumber thực thi một bước Given, nó sẽ cấu hình hệ thống ở trạng thái
được xác định rõ, chẳng hạn như tạo và định cấu hình các đối tượng hoặc thêm
dữ liệu vào cơ sở dữ liệu thử nghiệm.

Mục đích của các bước Given là đưa hệ thống về trạng thái đã biết trước khi
người dùng (hoặc hệ thống bên ngoài) bắt đầu tương tác với hệ thống (trong các
bước Khi). Tránh nói về sự tương tác của người dùng trong Given khuyết. Nếu
bạn đang tạo các trường hợp sử dụng, Given sẽ là điều kiện tiên quyết của bạn.

Có thể có một số bước Given (chỉ cần sử dụng And hoặc But cho số 2 trở lên để
dễ đọc hơn).

Mickey and Minnie have started a game I am logged in Joe has a balance of
£42Syntax:
Given [step description]
Ví dụ:
Given User login and navigate to Job Title page

When (Hành vi người dùng)

When: là xác định hành động được thực hiện bởi người dùng.
Các bước When được sử dụng để mô tả một sự kiện hoặc một hành động. Đây
có thể là một người tương tác với hệ thống hoặc có thể là một sự kiện được kích
hoạt bởi một hệ thống khác.

Rất khuyến khích bạn chỉ có một bước When trong mỗi Scenario. Nếu bạn cảm
thấy bắt buộc phải thêm nhiều bước When hơn, thì đó thường là một dấu hiệu
cho thấy bạn nên chia kịch bản thành nhiều kịch bản.
Syntax:
When [step description]
Ví dụ
Guess a word
Invite a friend
Withdraw money
When User click on Add New button in Job Title page

Then (Kết quả mong muốn)

Việc sử dụng từ khóa 'then' là để xem kết quả sau hành động trong bước when.
Tuy nhiên, bạn chỉ có thể xác minh những thay đổi đáng chú ý.
Các bước Then được sử dụng để mô tả một kết quả mong đợi, hoặc kết quả.

Định nghĩa bước của bước Then nên sử dụng một xác nhận để so sánh kết quả
thực tế (những gì hệ thống thực sự làm) với kết quả mong đợi (bước mà hệ
thống nói là phải làm).

Một quan sát nên được trên một đầu ra quan sát được. Đó là, một cái gì đó ra
khỏi hệ thống (báo cáo, giao diện người dùng, tin nhắn), và không phải thứ gì
đó chôn sâu bên trong nó (như cơ sở dữ liệu).

Ví dụ:
Xem từ đã đoán là sai Nhận lời mời Nên nuốt thẻ Trong khi nó có thể hấp dẫn
để thực hiện các bước Then chỉ cần tìm trong cơ sở dữ liệu - chống lại sự cám
dỗ đó!

Bạn chỉ nên xác minh kết quả có thể quan sát được cho người dùng (hoặc hệ
thống bên ngoài), và cơ sở dữ liệu thường thì không.
Syntax:
Then [step description]
Then the job title name <jobTitleName> and the description
<description> displays

And & But (Kết hợp nhiều từ khóa)

Nếu bạn có một số Given, When, hoặc Then, bạn có thể viết:

Hoặc, bạn có thể làm cho nó đọc trôi chảy hơn bằng cách viết:

Syntax:
And [step description]
And I write "EmailAddress" with "anhtester@gmail.com"
But [step description]
But I should see "Welcome Anh Tester Blog"

Given, When, Then, And, But là các bước kiểm tra. Bạn có thể sử dụng chúng
thay thế cho nhau. Trình thông dịch không hiển thị bất kỳ lỗi nào. Tuy nhiên,
chúng chắc chắn sẽ không có ý nghĩa gì khi đọc.
Ví dụ case Login:

Cho biết Trang đăng nhập đang mở

Khi tôi nhập tên người dùng, mật khẩu và nhấp vào nút Đăng nhập
Thì tôi sẽ được chuyển đến trên Trang chủ

Scenario Outline (Gom Scenario có cùng kịch bản nhưng khác dữ liệu lại với
nhau)
Các Scenario Outline từ khóa có thể được sử dụng để chạy
cùng Scenario nhiều lần, với sự kết hợp khác nhau của các giá trị.
Từ khóa Scenario Template là một từ đồng nghĩa của từ khóa Scenario
Outline.
Việc sao chép và dán các kịch bản để sử dụng các giá trị khác nhau nhanh chóng
trở nên tẻ nhạt và lặp đi lặp lại:
Scenario: eat 5 out of 12
Given there are 12 cucumbers
When I eat 5 cucumbers
Then I should have 7 cucumbers

Scenario: eat 5 out of 20

Given there are 20 cucumbers
When I eat 5 cucumbers
 Then I should have 15 cucumbers
Chúng ta có thể thu gọn hai kịch bản tương tự này thành một Scenario
Outline.
Các phác thảo kịch bản cho phép chúng tôi diễn đạt chính xác hơn các tình
huống này thông qua việc sử dụng một mẫu với < >các tham số được giới hạn:
Scenario Outline: eating
Given there are <start> cucumbers
When I eat <eat> cucumbers
Then I should have <left> cucumbers

Examples:
| start | eat | left |
| 12 | 5 | 7 |
| 20 | 5 | 15 |

Examples
A Scenario Outline phải chứa một hoặc nhiều Examples (hoặc Scenarios)
phần. Các bước của nó được hiểu như một mẫu không bao giờ được chạy trực
tiếp. Thay vào đó, Scenario Outlinechạy một lần cho mỗi
hàng trong Examples phần bên dưới nó (không tính hàng tiêu đề đầu tiên).
Các bước có thể sử dụng các tham số<> được phân tách tham chiếu đến các tiêu
đề trong bảng ví dụ. Cucumber sẽ thay thế các tham số này bằng các giá trị từ
bảng trước khi nó cố gắng khớp bước với định nghĩa bước.
Bạn cũng có thể sử dụng tham số trong step arguments.

Example
Đây là một ví dụ cụ thể mà minh họa một quy tắc kinh doanh. Nó bao gồm một
danh sách các bước như trên.
Từ khóa Scenario là một từ đồng nghĩa của từ khóa Example.
Bạn có thể có bao nhiêu bước tùy thích, nhưng chúng tôi khuyên bạn nên thực
hiện 3-5 bước cho mỗi ví dụ. Có quá nhiều bước sẽ khiến ví dụ mất đi sức mạnh
biểu đạt như một đặc tả và tài liệu.
Ngoài việc là một đặc tả và tài liệu, một ví dụ cũng là một bài kiểm tra . Nhìn
chung, các ví dụ của bạn là một đặc tả thực thi của hệ thống.
Các ví dụ theo cùng một mẫu này:
 o Mô tả bối cảnh ban đầu ( Given các bước)
o Mô tả một sự kiện ( When các bước)
o Mô tả một kết quả mong đợi ( Then các bước)

Tham khảo thêm các từ khóa và các cú pháp Gherkin chi tiết hơn tại
đây Gherkin keywords

Step Argument
Trong một số trường hợp, bạn có thể muốn truyền nhiều dữ liệu hơn cho một
bước hơn là khớp trên một dòng. Với mục đích này, Gherkin có các Doc string
và Data table.

 Doc string
Doc String thuận tiện cho việc chuyển một đoạn văn bản lớn hơn sang
step definition.

Văn bản phải được bù bởi các dấu phân cách bao gồm ba dấu ngoặc
kép trên các dòng của riêng chúng:

Trong định nghĩa bước của bạn, ở đó, bạn không cần phải tìm văn bản này
và khớp nó trong mẫu của bạn. Nó sẽ tự động được thông qua như là đối
số cuối cùng trong định nghĩa bước.

Việc thụt lề mở "" "là không quan trọng, mặc dù thông lệ chung là hai
khoảng trắng từ bước kèm theo. Tuy nhiên, thụt lề trong ba dấu ngoặc kép
là rất quan trọng. Mỗi dòng của Doc String sẽ được khấu trừ theo" " . Do
đó, thụt vào bên ngoài cột mở ra
  Data table
Data table thuận tiện cho việc chuyển danh sách các giá trị sang
step definition.

Cũng giống như Doc String, Data table sẽ được chuyển đến Step definition làm
đối số cuối cùng.

Cucumber cung cấp API phong phú để thao tác các bảng từ trong Step
definition. Xem tài liệu tham khảo tại đây để biết thêm chi tiết.

Ví dụ về Gherkin
Ví dụ 1:
Feature: Update password

Scenario: Admin user can update the user password

Given I am in the HR system with an Admin account

When I update password of another user
Then I receive a message for updating password
successfully
And user password is updated to the new password
Ví dụ 2:
@Regression
Feature: Job Titles feature

Scenario Outline: User can add Job Title

Given User login and navigate to Job Title page
When User click on Add New button in Job Title page
And User enter job title name "<jobTitleName>" and
description "<description>"
And User click on Save button in Create Job Titles
dialog
 And enter "<jobTitleName>" on Job Titles search field
Then the job title name "<jobTitleName>" and the
description "<description>" displays
Examples:
| jobTitleName | description |
| Employee | Software Engineer |
Ví dụ 3:
Feature: Multiple site support
Only blog owners can post to a blog, except
administrators,
who can post to all blogs.

Background:
Given a global administrator named "Greg"
And a blog named "Greg's anti-tax rants"
And a customer named "Dr. Bill"
And a blog named "Expensive Therapy" owned by "Dr.
Bill"

Scenario: Dr. Bill posts to his own blog

Given I am logged in as Dr. Bill
When I try to post to "Expensive Therapy"
Then I should see "Your article was published."

Scenario: Dr. Bill tries to post to somebody else's

blog, and fails
Given I am logged in as Dr. Bill
When I try to post to "Greg's anti-tax rants"
Then I should see "Hey! That's not your blog!"

Scenario: Greg posts to a client's blog

Given I am logged in as Greg
When I try to post to "Expensive Therapy"
Then I should see "Your article was published."
✅ Các phương pháp sử dụng Gherkin tốt nhất
o Mỗi kịch bản nên thực hiện riêng biệt
o Mọi tính năng sẽ có thể được thực thi cùng
o Thông tin các bước phải được hiển thị độc lập
o Kết nối Kịch bản của bạn với các yêu cầu của bạn
o Theo dõi đầy đủ những tình huống nào nên được đưa vào tài liệu yêu cầu
o Tạo các bước mô-đun và dễ hiểu
o Cố gắng kết hợp tất cả các tình huống phổ biến của bạn

✅ Ưu điểm của Gherkin

o Gherkin đủ đơn giản để những người không phải lập trình viên có thể
hiểu được
o Các lập trình viên có thể sử dụng nó như một cơ sở rất vững chắc để bắt
đầu các bài kiểm tra của họ
o Nó làm cho Câu chuyện của người dùng dễ hiểu hơn
o Tập lệnh Gherkin có thể dễ dàng hiểu được bởi các nhà điều hành doanh
nghiệp và nhà phát triển
o Kiểm tra Gherkin nhắm mục tiêu các yêu cầu về sản phẩm
o Một tỷ lệ đáng kể các thông số kỹ thuật chức năng được viết dưới dạng
câu chuyện của người dùng
o Bạn không cần phải là chuyên gia để hiểu bộ lệnh Gherkin nhỏ
o Các trường hợp thử nghiệm Gherkin liên kết các thử nghiệm chấp nhận
trực tiếp với các thử nghiệm tự động
o Phong cách viết các trường hợp kiểm thử dễ dàng hơn để sử dụng lại mã
trong các bài kiểm tra khác

✅ Nhược điểm của Gherkin

o Nó đòi hỏi mức độ tham gia và cộng tác cao
o Có thể không hoạt động tốt trong tất cả các tình huống
o Các bài kiểm tra được viết kém có thể dễ dàng làm tăng chi phí bảo trì
kiểm tra
✅ Tóm lược
o Gherkin là định dạng cho các thông số kỹ thuật của Cucumber
o Gherkin là ngôn ngữ hướng dòng giống như YAML và Python
o Gherkin Scripts kết nối khái niệm nhân quả của con người với khái niệm
phần mềm về đầu vào / quy trình và đầu ra
o Feature, Background, Scenario, Given, When, Then, And, But các từ khóa
thường được sử dụng trong Gherkin
o Trong Gherkin, mỗi kịch bản nên thực thi riêng biệt
o Ưu điểm lớn nhất của Gherkin là đủ đơn giản để những người không phải
lập trình viên có thể hiểu được
o Gherkin Test có thể không hoạt động tốt trong tất cả các loại tình huống

Nguồn
 https://www.guru99.com/gherkin-test-cucumber.html
 https://cucumber.io/docs/gherkin/reference/