Áp dụng BDD cho dự án Agile (phần 3)

Bài cuối trong series về việc dùng BDD, mình sẽ tập trung các bestpractice cho việc viết ngôn ngữ dưa chuột để mọi người có thể áp dụng vào dự án tốt nhất

img005

Lưu ý với features file

Không dài dòng

Feature tốt nhất là được mô tả ngắn gọn, không rườm rà, sướt mướt, than nghèo kể khổ. Ngay bản thân anh em chúng ta đọc mấy cái dài dài là đã chán rồi thì việc đưa ra cho stakeholder đọc người ta cũng cảm thấy như mình thôi chính vì vậy điều kiện đầu tiên cho feature đó là mô tả phạm vi và nội dung chức năng trong 1 câu duy nhất, chỉ 1 câu duy nhất :3

cbffe82f4ec4de731994accee8a86fed

Thống nhất một format chuẩn

Việc áp dụng một format chuẩn sẽ giúp những anh em sau tham gia vào dự án có thể dễ dàng hiểu được feature. Ở đâu mình có 1 mẫu anh em tham khảo

Template

Feature: [One line describing the story]

[Optional — Feature description]

Scenario: [One line describing the scenario]

Given [context]

And [some more context]…

When [event]

Then [outcome]

And [another outcome]…

Lưu ý với background

Bất cứ lúc nào có thể thì 500 anh em ta nên sử dụng backgroud cho các shared steps để dùng chung cho tiện

Giữ cho background ngắn gọn

Background không nên dài quá 4 dòng và nên được hiểu như một điều kiện tiên quyết cho mỗi scenario. Điều này làm cho mấy anh đọc cái feature của mình ấy à, luôn giữ được đầu óc thông thoáng không phải quan tâm cái background làm gì ví như cái việc mình Given một người dùng đã đăng nhập thành công

Không để các công việc liên quan đến kĩ thuật trong background

500 anh em ta nên tránh việc sử dụng các ngôn ngữ hightech ở bước này. Ví dụ như không dùng để mô tả các bước như bật, tắt Apache, IIS; xóa cache ứng dụng hay drop table trong CSDL bởi vì chả bố con thằng nào nó quan tâm mấy cái đó đâu :v Viết vào chỉ làm thêm rối cho người đọc thôi. Nếu các anh em cần thực hiện những cái đó thì cứ cài đặt nó trong các step không cần phải ghi ra trong background

Không bao giờ sử dụng tag trong background

Anh em có thể sử dụng tag trong scenario hay feature nhưng không được sử dụng trong background. Lý do thì đừng có hỏi cứ tuân theo thôi. Quân lệnh như sơn \m/

funny-luggage-tags

Không bao giờ sử dụng background cho file feature mà chỉ có một scenario (miễn trình bày lý do)

Tiếp theo là scenarios và steps

Nghĩ kĩ xem nên dùng Scenarioo hay Scenario Outline

Việc quyết định có bao nhiêu examples sẽ quyết định cho việc sử dụng các loại scenario. Nếu anh em ta có một scenario với một example thì chỉ nên sử dụng scenario. Còn khi scenario có nhiều example, scenario outline sẽ giúp anh em ta tránh việc cài đặt quá nhiều các steps thừa chưa kể còn làm tăng khả năng đọc hiểu feature cũng như bảo trì

Giữ scenario ngắn gọn bằng cách che giấu chi tiết cài đặt

Việc include đầy đủ các steps là không nên vì tốn khơ khớ thời gian cũng như làm cho scenario quá dài với hàng đống AND steps gây khó khăn cho việc đọc hiểu. Tuy vậy thì vẫn phải mô tả chi tiết đầy đủ để hiểu được nội dụng của scenario. Không sử dụng các thuật ngữ kĩ thuật hay việc cài đặt chi tiết như sử dụng Xpath hay Css selector trong steps. Những cái này cần invisble với ngưởi đọc

the_2ad11b_1256534

Sử dụng GIVEN-WHEN-THEN đúng thứ tự

Luôn luôn bắt đầu scenario với GIVEN thậm chí là sử dụng GIVEN trong background. Scenario sẽ khó đọc hơn nhiều nhiều đấy nếu bạn đưa thứ tự các GIVEN-WHEN-THEN lung tung

Việc sử dụng Examples trong scenario outline

Viêc sử dụng examples là một cách tốt để cover toàn bộ các scenario trong một lần nhưng anh em cần phải sử dụng nó với các examples có ích chứ không lại examples mà mười cái như một thì không có tác dụng lắm :|.Không nên sử dụng quá 10 examples cho 1 scenario outline

Giữ cho scenario độc lập

Scenario nên chạy độc lập mà không phụ thuộc vào bất cứ scneario nào khác. Điều này giúp cho quá trình debug nhanh hơn khi có cái gì đó nó sai sai mà anh em ta cảm nhận đượcbd10948b3ea22e8cb119ed98dec57cd07143d7d40a2ca81c20baf750cc00030e

Tránh conjunctive steps

Gherkin có các AND và BUT để cho chúng ta sử dụng do đó cần tránh việc viết steps mà include các từ ANd hay BUT vào mà không nằm ở đầu Step

Ví dụ

Scenario: Homepage

Given I am on the homepage and scrolled page down

Scenario cho cả các case fail

Anh em đồng đạo đặc biệt lưu ý việc cài đặt feature phải đúng với các giá trị business để có thể đảm bảo cho việc cover được đầy đủ các trường hợp từ valid input đến invalid input

DRY: Dont repeat you

Luôn luôn tìm kiếm cách để tái sử dụng (refactor) lại đống steps mà không phụ thuộc vào feature. Anh em đồng đạo nên tạo ra được 1 thư viện các steps để có thể mang từ project này sang project kia, điều này làm cho việc copy nó tiện =))

dontrepeatyourself_motivator_2

Cuối cùng thì là tags

Tagging giúp chúng ta quản lý, sắp xếp được feautre và scenario trong các project BDD. Các feature files sẽ nằm rải rác ở rất nhiều chỗ trong thư mục A, thư mục B hoặc thư mục C; dùng tag sẽ giúp ta filter được

Ví dụ chúng ta có 1 danh sách sceanrio cho việc nghe nhạc trên Zing thì thể sử dụng tag @music ==> Nếu muốn tìm tất các scenario liên quan đến Zing, chúng ta dễ dàng tìm kiếm theo tag @music là được

Tên cho mấy cái tag

Đặt tên tag cũng như đặt tên con ấy mà. Suy nghĩ đau đầu lắm 😀

hinhtenkylacfuedivh_vcmy

Anh em có thể sử dụng các tag thông dụng sau

Frequency of Execution: @daily, @hourly, @nightly

Dependencies: @database, @fixtures, @local, @proxy

Progress: @wip, @todo, @implemented, @blocked

Level: @functional, @acceptance, @smoke, @sanity

Environment: @integration, @test, @stage, @live

Tag thông minh

Không sử dụng quá nhiều tag trong dự án vì điều này sẽ làm bạn đau đầu để quản lý đấy.

Không sử dụng cùng một tag cho scenario và feature

Xóa bỏ các tag @wip mỗi khi làm xong

Chốt

Tóm lại sau khi đọc qua mấy phần về BDD thì các anh em xem có áp dụng được nó cho dự án của mình không thì tự anh em quyết định nhé. Xác định dùng nó thì phải mất công mất sức hơn so với bình thường rồi, trình độ của anh em trong team cũng phải ở một mức nhất định để việc áp dụng không bị delay quá. Anh em có thể tham khảo bài viết ở trang kipalog để xem xét nhé

http://kipalog.com/posts/BDD-co-re-hon-khong

 

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s