Gherkin và Phát triển phần mềm hướng hành vi BDD

Bài viết hôm nay chúng ta sẽ tìm hiểu về một hướng phát triển phần mềm với tên gọi là Behavior Driven development (BDD) và cách sử dụng Gherkin một ngôn ngữ được sử dung để viết các tài liệu dùng trong BDD. Nội dung của bài viết gồm 3 phần như sau:

Giới thiệu về BDD
Test-driven Developement (TDD) và TDD trong BDD
Cú pháp của Gherkin.

Chúng ta cùng bắt đầu!

1. Giới thiệu BDD

Giới thiệu chung

Behavior-driven Development (BDD) là một quy trình phát triển phần mềm ban được tạo ra theo tư tưởng của TDD (Test-driven Development). BDD sử dụng những ví dụ để mô tả hành vi của hệ thống mà được viết bằng một ngôn ngữ dễ đọc và dễ hiểu đối với tất cả những người tham gia vào quá trình phát triển phần mềm như Developer, Business Analyst, Customer hay QC engineer.

Những ví dụ được dùng trong BDD sẽ được dùng với 2 mục đích chính:

Chuyển được thành những executable specification
Được dùng như acceptance test

Những tính năng chính của BDD

BDD tập trung vào những điểm sau:

Thứ nhất, cung cấp một quy trình, một bộ công cụ chung nhằm cải thiển việc giao tiếp giữa software developer, business analyst, stakeholder để cùng làm hợp tác để tạo ra sản phẩm phần mềm đem lại giá trị về business
Thứ 2, BDD chỉ quan tâm đến những gì phần mềm nên làm và không nên làm, BDD không tập trung vào cách hiện thực phần mềm
Cuối cùng, BDD không những đảm bảo về khả năng hoạt động của phần mềm mà còn đảm bảo phần mềm đáp ứng được các mong muốn của customer.

2. Test-driven Developement (TDD) và TDD trong BDD

Khi tìm hiểu về BDD ta sẽ thấy có nhiều tài liệu cho rằng "BDD được suy ra từ TDD". Vì vậy để hiểu được về BDD, chúng ta cần có một cái nhìn tổng quan về TDD.

Test-last approach

Trong quy trình phát triển phần mềm truyền thống, bug sẽ được phát hiện sau khi kiểm thử phần mềm, tức là quá trình test phải đợi cho đến khi một bước nào đó trong quá trình phát triển phần mêm hoàn thành thì mới thực hiện được. Đây gọi là Test-last approach. Cách tiếp cận này gặp phải một số vấn đề như sau:

Thời gian phát triển phần mềm có hạn, mọi sự tập trung đổ dồn vào tính hoàn thiện của sản phẩm, dẫn đến việc testing bị bỏ qua hoặc làm không tới nơi
Unit test - cái mà đáng ra phải được thực hiện bởi dev, thường hay bị bỏ qua vì mind-set của họ cho rằng: Họ là dev không phải tester; Test phần mềm là trách nhiệm của Tester và thậm chí có một số thanh niên cho rằng Họ code đủ chất lượng rồi, sẽ không có BUG.

Và những vấn đề này sẽ kéo theo những hệ quả như:

Chất lượng của sản phẩm được bàn giao bị ảnh hưởng
Trách nhiệm về chất lượng của sản phẩm bị quy kết hoàn toàn về tester
Chi phi fix bug cực kì cao khi phát hiện càng trễ
Không đáp ứng được khách hàng, uy tín của công ty bị ảnh hưởng

Vì những lý do trên, nên Test-first được ra đời

Test-first approach

Test-first ra đời để thay thế cho hướng tiếp cận cũ viết-code-xong-test bằng hướng tiếp cận mới là viết-test-xong-code. Nhìn chung, khi tiếp cận theo hướng test-first thì developer có nhiệm vụ viết Unit test cho một module nào đó trước khi thực sự hiện thực module đó bằng code. Từ đó, module được viết ra với mục tiêu pass hết các Unit test đã được viết cho nó.

Ba luật của TDD được đưa ra bởi Uncle Bob:

-You are not allowed to write any production code unless it is to make a failing unit test pass.

- You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures.

- You are not allowed to write any more production code than is sufficient to pass the one failing unit test.

Hay ta có thể tóm gọn lại như sau:

Write only enough of a unit test to fail.
Write only enough production code to make the failing unit test pass.

Red-Green-Refactor cycle

Red-Green-Refactor (RGR) cycle

Từ các rule trên, TDD process có thể được mô ta thông qua Red-Green-Refactor (RGR) cycle. Mô hình này gôm 3 phase:

Red phase: Viết failed unit test
Green phase: Viết code để pass những cái unit test ở Red phase
Refactor phase: Sau khi code đã pass, tiến hành refactor code như loại bỏ code duplication hay cải thiện code để đáp ứng acceptance standard...

3. Cú pháp Gherkin

Giới thiệu Gherkin

Gherkin là một ngôn ngữ giúp mô tả các hành vi của hệ thống phần mềm mà không cần đi sâu vào chi tiết hiện thực (code). Gherkin được dùng để viết các user story hay các feature của phần mềm. Cú pháp Gherkin bao gồm 2 nhóm keyword chính và phụ

Keyword chính:

Feature: Mô tả các tính năng của phần mềm ở mức high-level và nhóm các Scenario liên quan
Rule: là một keyword dùng để mô tả 1 business rule nào đó cần được hiện thực, nó bổ sung thêm thông tin cho Feature.
Example hay Scenario: thể hiện một ví dụ cụ thể mô tả cho business rule. Mỗi Scenario thường gồm nhiều Steps (nên là từ 3-5 step) mô tả hành vi của business rule
Steps: Mỗi Steps thường được bắt đầu bằng các keyword như sau:

Given: Mô tả ngữ cảnh ban đầu của hệ thống, thường mô tả một thứ đã diễn ra trong quá khứ. Mục đích của Given là đặt hệ thống vào một trạng thái đã biết trước khi người dùng tương tác với hệ thống ở When
When: Mô tả 1 sự ki ện hay hành động mà người dùng tương tác tới hệ thống hoặc hệ thống được trigger từ hệ thống khác
Then: Mô tả kết quả mong muốn sẽ xảy ra từ sự kiện hay hành động ở When. Then nên mô tả một kết qủa có thể thấy được như UI hay report thay vì sự thay đổi sâu bên trong như ở Database
And và But: Được dùng để nối nhiều Given/When/Then với nhau

Background: Được dùng để bổ sung thêm ngữ cảnh cho các Scenario của Feature. Background có thể có 1 hay nhiều Given
Scenario Outline/Template: dùng để kết hợp nhiều Scenario với các giá trị khác nhau.
Examples: mỗi Scenario Outline luôn đi kèm với Examples để mô tả các giá trị khác nhau dùng trong Scenario đó

Keyword phụ:

Docs String (""")
Data Table (|)
Tag (@)
Comment (#)

Ví dụ

Để hiểu rõ hơn chúng ta sẽ thử làm mộ ví dụ sử dụng các keyword của Gherkin để mô tả một tính năng của phần mềm.

Giả sử phần mềm có tính năng Log in như sau: Người dùng được phép log in bằng email, password. Nếu đăng nhập thành công thì sẽ chuyển đến trang chính, nếu đăng nhập thất bại thì sẽ thông báo lỗi cho người dùng.

Chúng ta sẽ dùng Gherkin để mô tả tính năng Login như sau

Feature: Log in 

 # This line is Short description of the feature

As a user, I want to log in the system by email and password

Background: User created

Given At least one user created in the system

Scenario Outline: Login successfully

Given I am in Login Screen

When I enter <email> in Email input

And I enter <password> in Password input

And I click Login button

Then I log in system successfully

And System navigate to Main Screen

Examples:

 | email | password |

 | abc@gmail.com | P@ssword |

Scenario Outline: Login failed

Given I am in Login Screen

When I enter <email> in Email input

And I enter <password> in Password input

And I click Login button

Then System display alert with <error>

And I am still in Login Screen

Examples:

 | email | password | error |

 | not_register@gmail.com | P@ssword | Email not registered |

 | wrong_password@gai | oneTw0 | Wrong email or password |

 | invalidEmail | P@ssword | Invalid email format |

Kết luận:

Như vậy chúng ta đã đi qua tìm hiểu về BDD, TDD, cũng như cách sử dụng cú pháp Gherkin để viết Specification mô tả các tính năng của phần mềm. Hi vọng qua bài viết này có thể giúp các bạn có thể đọc-hiểu cũng như viết được các Software Specification theo hướng BDD bằng Gherkin.

Nếu bài viết hay các bạn có thể chia sẻ để mọi người cùng đọc. Nếu có ý kiến đóng góp về nội dung các bạn đừng ngần ngại để lại comment cho mình bên dưới bài viết này.

Xin cảm ơn!

Julian Dong