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:

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)

1. Feature

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.

2. Rule

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ụ:

3. Example

Đây là một Example cụ thể minh họa một quy tắc nghiệp vụ. Nó bao gồm một danh sách các bước. Từ khóa Example là một từ đồng nghĩa củatừ Scenario.

Bạn có thể có bao nhiêu bước tùy thích, nhưng tôi khuyên bạn nên giữ số ở mức 3-5 mỗi ví dụ. Nếu chúng trở nên dài hơn thế, chúng sẽ mất sức mạnh biểu cảm như đặc điểm kỹ thuật và tài liệu.

Các Example theo mô hình tương tự:

Mô tả bối cảnh ban đầu (Bước Given)
Mô tả một sự kiện (Bước When)
Mô tả một kết quả mong đợi (Bước Then)

4. 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:

5. Given

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 £42

6. When

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.

Ví dụ:

Guess a word

Invite a friend

Withdraw money

7. Then

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.

8. And/But

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:

9. Background

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.

10. Scenario Outline

Từ khóa Outline Scenario có thể được sử dụng để chạy cùng một Scenario nhiều lần, với các kết hợp giá trị khác nhau.
Scenario Template là từ đồng nghĩa của Scenario Outline.
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:

Chúng ta có thể thu gọn hai kịch bản tương tự này thành Scenario Outline.

Các Scenario Outline cho phép chúng ta thể hiện chính xác hơn các kịch bản này thông qua việc sử dụng một mẫu với các tham số <> phân định:

Scenario Outline phải có phần Examples (hoặc Scenarios). Các bước của nó được hiểu là một mẫu không bao giờ được chạy trực tiếp. Thay vào đó, Outline Scenario được chạy một lần cho mỗi hàng trong phần Example 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 mà các tiêu đề tham chiếu trong bảng Examples. 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.

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

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

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

Tài liệu tham khảo:

Bài viết được dịch từ trang web sau: https://cucumber.io/docs/gherkin/reference/

Xem thêm các bài viết chia sẻ về kiến thức kiểm thử phần mềm tại đây

https://vinatester.com/