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

Ở series bài viết trước mình có giới thiệu cho các bạn về Jenkins, 1 công cụ khá là hay ho cho quy trình phát triển phần mềm agile. Tiếp theo series đó, mình sẽ giới thiệu cho các bạn 1 công cụ trong quy trình phát triển agile nữa. Công cụ này là gì  thì mĩnh sẽ giới thiệu sau nhé :v Còn trong bài đầu tiên của series mình sẽ tập trung về hướng phát triển phần mềm trong agile.

Không biết mọi người đã ai nghe về các loại driven develop chưa nhỉ? Mình tạm thời bây giờ thì có biết qua mấy loại mặc dù chưa áp dụng được cái nào =))

  • Test driven develop hay TDD: phát triển hướng kiểm thử
  • Behavior driven develop hay BDD: phát triển hướng hành vi
  • Domain driven develop hay DDD: phát triển hướng domain (đại loại là tập trung vào nghiệp vụ)

Ai làm agile chắc cái TDD thì nghe là hiểu ấy nhỉ :3 Thôi mình cứ nói lại để cho mọi người cùng nắm được.

TDD là chi

TDD là mô hình phát triển mà đặt trọng tâm vào việc kiểm thử phần mềm. Chính vì vậy mà phần mềm mà được áp dụng theo TDD đều khá là ít lỗi do tiêu chí của TDD đó là chúng ta sẽ test-firset sau đó là điều chỉnh mã nguồn refactor để đáp ứng testcase

687474703a2f2f692e696d6775722e636f6d2f525165324e51542e6a7067.jpg

Khi nhận 1 requirement từ khách hàng thì việc đầu tiên của mấy a dev đó là ngồi soạn testcase sau đó mới chạy luôn cho nóng :3 THôi khỏi trình bày thì nó toi là cái chắc. Đó là cái màu đỏ đầu tiên trong hình :D. Sau đó thì các chàng trai đó sẽ tiến hành sẽ bắt đầu viế code để chạy được chương trình. Yeah ra màu xanh Green (y) ý nghĩa cái hình 2. Ăn mừng cái nào :))


Thành công rồi thì các anh dev của chúng ta sẽ tiến hành làm mịn màng code như Nivea tẩy rửa da mặt. Cái này là Refactor(3)

nivea_o_307710

Ủa sao nghe cái này nó cứ ngược ngược với cái mình hay làm hay sao ẩy nhỉ 😕

questionmarkfunnyface

Mô tả lại cái hình ở trên thì chúng ta có thể tóm gọn lại

Red (1): đối với chương trình thay vì nhảy vào viết code chi tiết ngay như mấy con thiêu thân thì chúng ta tạo khung trước ví dụ như chỉ viết tên hàm, tên scripts bỏ qua phần thâncach-diet-duoi-con-thieu-than

Green(2): viết test cho khung đầy đủ

Refactor (3): đắp dần đắp dần các đống code vào cái khung đã cos để pass các test

==> Mục đích của việc này có tác dụng đó là sẽ tập trung được vào phân tích yêu cầu và thiết kế chương trình hướng đến người dùng (end-users) hơn là đầu vào, đầu ra (input, output) của tính năng chương trình như mô hình waterfall

Việc áp dụng TDD sẽ góp phần làm khoảng cách giữa công việc phát triển và kiểm thử được kéo gần vào nhau, tối ưu quy trình :3

Thế bây giờ mà mấy a dev làm cả nhiệm vụ cảu test thế mấy chị tester đi đâu mất rồi 😐

gadu_gadu_funny_icon_by_syxxia

BDD là gì

Yên tâm là mấy chị vẫn có việc nhé nhưng bây giờ công việc của các chị cũng có ý nghĩa hơn nhiều (y). Có 1 mô hình mới được đưa ra dựa trên TDD, phải nói là mở rộng của TDD thì đúng hơn đó là BDD (behavior driven develop: phát triển hướng hành vi). Chính vì vậy mà tuy 2 mà 1, tuy 1 mà 2 nhé :*

Vai trò của các chị test nhà mình ấy à. Nhiều việc phết đấy nhé:

Thay vì có sản phầm hoàn thiện, thì các chị cũng nhảy vào viết mã. Nghe ghê chưa 😀 khác hẳn công việc vẫn làm như viết testcase ra Excel nhé =)). Các mã nguồn này được viết theo hướng ngôn ngữ tự nhiên, y như là văn nói ấy. Đây các bạn xem thử 1 kịch bản test 😀 như 1 bài văn luôn

Feature: Some terse yet descriptive text of what is desired
  In order to realize a named business value
  As an explicit system actor
  I want to gain some beneficial outcome which furthers the goal

  Scenario: Some determinable business situation
    Given some precondition
      And some other precondition
     When some action by the actor
      And some other action
      And yet another action
     Then some testable outcome is achieved
      And something else we can check happens too

Cái kịch bản này được viết dựa trên requirement của hệ thống cũng như hành vi của người dùng tương tác.

Với việc phát triển thế này thì các chị test phải giúp các anh dev trong việc giải thích và xây dựng chương trình mang tính thực tiễn với người dùng hơn trước khi bắt tay vào xây dựng chương trình

friend_match_icon

Thế này thì anh dev với chị test ấy à sẽ phải liên hệ mật thiết với nhau để xây dựng code với scripts test theo mô hình TDD. Nghe vẻ tình cảm hẳn ấy nhỉ. BDD có khi lại giúp họ tìm được trái tim nhau =))

14569586width3d178height3d178

Với việc sử dụng BDD, thì kịch bản test sẽ được phân thành 2 cái đó là unittest do mấy chàng dev khỏe khoắn sẽ làm mấy Unit còn các chị test liễu yếu đào tơ thì làm cái to tát hơn đó là feature/acceptance test. HÌnh vẽ bên dưới sẽ thể hiện quy trình áp dụng cho BDD

 

bdd-cycle-around-tdd-cycles

Ai viết BDD?

Do BDD đề cao sự cộng tác giữa các thành viên trong dự án cũng như các bên liên quan. Vì vậy, tất cả những người này sẽ xây dựng nên file BDD để đưa ra một cái nhìn chung nhất, chính xác nhất về yêu cầu của dự án. Không mọi người lại nghĩ chỉ có mấy chị test viết thì không đúng đâu nhé

f2699213f5746b2a147925e310f79167

Các chị ấy có thể viết trước các feature rồi đưa cho các thành viên trong dự án, các stakeholder để có thể nhận được góp ý, đánh giá xem đã viết thế đúng với yêu cầu của chương trình chưa, viết thế thì hành vi của người dùng đó là đúng hay sai….

So sánh với TDD

BDD là cách diễn đạt dễ hiểu hơn TDD, kiểu “lựa lời mà nói cho vừa lòng nhau”.

Ở TDD thì nhìn testcase là thấy code (các anh dev lên đỉnh), còn ở BDD thì nhìn thấy testcase là thấy yêu cầu (khách hàng lên đỉnh). Chính vì vạy thì TDD tương đương với cái verification còn BDD tương ứng với specificaiton

unnamed

Nghe hay đấy, thế tôi muốn áp dụng thì thế nào?

Hiện tại thì có khá nhiều công cụ hỗ trợ cho việc phát triển theo hướng BDD nhé. Mình liệt kê 1 số thằng cho các bạn

RSpec: cho thằng ruby

Cucumber: thằng này bắt nguồn từ bên Ruby. Giờ thì có thêm bản cho java 😀

SpecFlow: cháu này được dùng cho thằng C#. Có thể coi nó là Cucumber for .NET

Behat + Mink: 2 thằng này thì dùng cho PHP :3

Còn các thằng khác thì mình chả rõ lắm :3 ai biết thì đóng góp thêm nhé

CHốt

Phần tiếp theo mình sẽ giới thiệu về cách áp dụng BDD cho các kịch bản test nhé. Viết hơn 1000 từ rồi nhọc 😛

 

Advertisements

2 thoughts on “Áp dụng BDD cho dự án Agile (phần 1)

  1. Pingback: 1 năm tham gia Hội nhà văn | Code, code and more code

  2. Pingback: Chào mừng bài viết thứ 50 | Code, code and more code

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