Acceptance Test khác Unit Test thế nào?
Software Engineering
36
Testing
24
White

Ngoc Dao viết ngày 22/03/2016

Test là một trong những giáo lý được đề cao nhất trong phương pháp phát triển phần mềm Agile. Khó mà nói rằng bạn đã Agile, nếu bạn không viết nhiều test tự động, và không viết trước khi thực sự viết chương trình.

Nhưng theo kỷ luật của Agile, phải viết đến hai loại test tự động. Unit test: viết do lập trình viên, vì lập trình viên, bằng ngôn ngữ lập trình. Acceptance test: viết do bộ phận kinh doanh (và QA), vì bộ phận kinh doanh, bằng ngôn ngữ cấp cao (như FitNesse).

Vấn đề là, đối với lập trình viên ý nghĩa của hai loại test này là gì? Qui trình thế nào? Nên viết unit test và chương trình trước, rồi sửa chương trình để pass acceptance test? Hay viết chương trình để pass acceptance test rồi mới đến unit test?

Ngoài ra, sao lại cần hai loại test? Không thừa hay sao?

Đúng là hai loại test cùng test cùng một vật. Thật ra, đấy là mấu chốt. Unit test viết do lập trình viện để chắc chắn chương trình chạy đúng ý họ. Acceptance test viết do bộ phận kinh doanh (và QA) để chắc chắn chương trình chạy đúng ý họ. Cả hai phối hợp để chắc chắn cả lập trình viên và bộ phận kinh doanh có cùng ý định.

Tất nhiên cũng có khác nhau về cấp độ. Unit test sục vào chương trình và kiểm tra những đơn vị độc lập nhau. Thực tế, lập trình viên phải tốn nhiều công sức để tách các thành phần của chương trình độc lập với nhau để có thể kiểm tra chúng độc lập. Do đó unit test ít khi kiểm tra nhiều phần tích hợp với nhau trong chương trình.

Acceptance test, mặt khác, hoạt động trên nhiều phần tích hợp nhau của chương trình. Chúng thường đưa input vào chương trình và kiểm tra output. Do đó, dù acceptance test có thể kiểm tra cùng một vật như unit test, đường đi của chúng rất khác nhau.

Qui trình

Nên viết acceptance test ở đầu mỗi chu trình. Khi họp, bộ phận QA và kinh doanh cần chọn ra story và biến chúng thành acceptance test tự động, viết bằng FitNess hoặc Selenium hoặc công cụ tự động hoá thích hợp nào đó.

Sau khi họp bàn kế hoạch làm project, thường vài acceptance test được đưa ra trong vòng một ngày. Mỗi ngày tiếp theo đó lại có thêm. Chúng thường được hoàn thành ở giữa mỗi chu trình của Agile. Nếu không, cần có thêm vài lập trình viên xắn tay giúp bộ phận kinh doanh viết cho xong.

Sử dụng lập trình viên theo cách này giống như cách hoạt động của van an toàn. Nếu thấy phải mở van an toàn thường xuyên, thì cần điều thêm nhân lực cho bộ phận QA hoặc BA. Nếu chẳng bao giờ phải mở van an toàn, có lẽ nên điều bớt người sang bộ phận viết chương trình.

Lập trình viên sử dụng acceptance test như là yêu cầu. Họ đọc những test này để biết story hoạt động thế nào.

Lập trình viên bắt tay viết story bằng cách chạy acceptance test cho story đó, và ghi chú xem cái gì thất bại. Sau đó họ viết unit test để ép mình viết từng phần chương trình để vượt qua acceptance test. Họ tiếp tục chạy acceptance test để xem story hoạt động được bao nhiêu phần trăm, và tiếp tục viết unit test và chương trình đến khi vượt qua mọi acceptance test.

Cuối chu trình tất cả acceptance test (và unit test) đều được vượt qua. Bộ phân QA không còn phải làm gì nữa. Họ không cần hì hục dùng thử chương trình một cách thủ công và so sánh kết quả với bản QA để kiểm tra chương trình có hoạt động đúng không, vì acceptance test đã chứng minh chương trình hoạt động đúng.

Điều này không có nghĩa bộ phận QA không phải đặt tay vào bàn phím và đặt mắt vào màn hình! Nhưng họ không dùng kịch bản để test thủ công (kịch bản đã được chuyển thành acceptance test để kiểm tra tự động)! Thay vì thế, họ sục sạo bới lông tìm vết. Người làm QA có tay nghề là người tìm ra cách mới để làm chương trình xảy ra lỗi.

Test thủ công theo kịch bản là vô đạo đức. Không những gây mệt mỏi, chán, và dể gây lỗi; nó còn sai ở chỗ biến con người thành máy móc. Nếu bạn có thể định ra kịch bản để kiểm tra, thì bạn có thể biến kịch bản đó thành acceptance test để việc kiểm tra được thực hiện tự động.

Tóm lại, bộ phận kinh doanh xác định cách hệ thống hoạt động bằng acceptance test. Lập trình viên chạy chúng để xem cần viết unit test gì. Unit test hướng họ viết chương trình để vượt qua cả hai loại test. Cuối cùng chương trình vượt qua tất cả test. Từ giữa mỗi chu trình Agile, bộ phận QA chuyển từ việc viết test tự động sang bới lông tìm vết một cách thủ công.

Tham khảo

Bình luận


White
{{ comment.user.name }}
Bỏ hay Hay
{{comment.like_count}}
Male avatar
{{ comment_error }}
Hủy
   

Hiển thị thử

Chỉnh sửa

White

Ngoc Dao

102 bài viết.
252 người follow
Kipalog
{{userFollowed ? 'Following' : 'Follow'}}
Cùng một tác giả
White
56 6
Làm thế nào để nâng cấp trang web mà không làm gián đoạn dịch vụ? Đây là câu hỏi phỏng vấn các công ty lớn thường hỏi khi bạn xin vào vị trí làm lậ...
Ngoc Dao viết 2 năm trước
56 6
White
32 0
Bài viết này giải thích sự khác khác nhau giữa hai ngành khoa học máy tính (computer science) và kĩ thuật phần mềm (software engineering), hi vọng ...
Ngoc Dao viết gần 2 năm trước
32 0
White
28 1
Nếu là team leader, giám đốc công ty hay tướng chỉ huy quân đội, vấn đề cơ bản bạn gặp phải là “hướng mọi người đi theo con đường bạn chỉ ra”. Thử...
Ngoc Dao viết gần 2 năm trước
28 1
Bài viết liên quan
White
1 1
Lập trình đôi (pair programming) là hình thức lập trình trong đó 2 người cùng hợp tác làm việc trên cùng màn hình (có thể khác bàn phím v.v.). Bài ...
Ngoc Dao viết gần 2 năm trước
1 1
White
5 1
Trong quyển sách Beyond Java, xuất bản vài năm trước có đoạn:Java has characteristics that many of us take for granted. You can find good Java deve...
Ngoc Dao viết gần 2 năm trước
5 1
{{like_count}}

kipalog

{{ comment_count }}

bình luận

{{liked ? "Đã kipalog" : "Kipalog"}}


White
{{userFollowed ? 'Following' : 'Follow'}}
102 bài viết.
252 người follow

 Đầu mục bài viết

Vẫn còn nữa! x

Kipalog vẫn còn rất nhiều bài viết hay và chủ đề thú vị chờ bạn khám phá!