Nhập môn BDD <ul><li>Waterfall </li></ul><ul><li>Agile </li></ul><ul><li>TDD </li></ul><ul><li>BDD </li></ul>Đào Thanh Ngọc
<ul><li>Q: Tại sao con gà băng qua đường? À quên tại sao lập trình viên lại viết chương trình? A: Để thoả mãn yêu cầu của ...
Phương pháp phát triển phần mềm <ul><li>Để thanh toán project, qui trình luôn gồm 5 phần: phân tích yêu cầu, thiết kế, viế...
Waterfall <ul><li>Là phương pháp phát triển phần mềm cổ truyền, “hạ sách” (←  sách lược default, không nghĩ ra cách gì khá...
Agile <ul><li>Là cách đánh du kích, tiết kiệm từng viên đạn, tính toán từng cân lương thực </li></ul><ul><li>Thanh toán từ...
google: “xoắn ốc” Mác <ul><li>Dân nhậu sau thời gian hiến gan và bao tử cho rượu Tây, bia lon thì nay tìm về rượu nấu, rượ...
Agile www.woods-info.co.jp
Agile www.rallydev.com
Waterfall VS Agile <ul><li>Còn đang tranh luận: project lớn (← thế nào là lớn?) nên dùng waterfall, nhỏ nên dùng agile? </...
Waterfall VS Agile behaviour-driven.org
Lợi ích của Agile <ul><li>Early Return on Investment: thấy thành quả của project ngay do cứ vài ngày lại có small release,...
Agile và offshore <ul><li>Agile cung cấp nhiều mẹo (practices)‏ </li></ul><ul><li>Mẹo khó dùng cho offshore: khách và lập ...
Agile và test <ul><li>Test tự động là yếu tố sống còn của agile, trong vòng xoắn ốc luôn phải có test! </li></ul><ul><li>L...
TDD, BDD là gì? Cộng sản Cuba Trung Quốc Việt Nam ... Agile TDD (Test Driven Development)‏ BDD (Behavior Driven Developmen...
TDD = BDD <ul><li>Một cách chặt chẽ: 2 cái là 1 </li></ul><ul><li>Là design hơn là test, test chỉ là hệ quả (hiểu lầm thườ...
TDD = BDD <ul><li>(1) Đối với từng phần của chương trình, thay vì bộp cái coding chi tiết ngay, tạo khung trước (ví dụ: ch...
TDD VS BDD <ul><li>Một cách thiếu chặt chẽ: </li></ul><ul><li>BDD = functional test = interface/specification test = lôi t...
TDD VS BDD <ul><li>BDD là cách diễn đạt dễ hiểu hơn TDD (“lựa lời mà nói cho vừa lòng nhau”)‏: TDD = assert, BDD = should ...
Vấn đề của TDD <ul><li>Lập trình viên cằn nhằn: </li></ul><ul><ul><li>Có chút xíu mã, viết test làm quách gì? </li></ul></...
Vấn đề của TDD <ul><li>Tính chỉ dẫn: </li></ul><ul><li>Bắt đầu từ đâu? </li></ul><ul><li>Cần test cái gì?  </li></ul><ul><...
BDD giải quyết vấn đề của TDD <ul><li>Làm rõ mục đích: TDD/BDD = spec first (design, documentation), chứ không phải test f...
Lợi ích của BDD <ul><li>Các lợi ích của Agile </li></ul><ul><li>1 phát 2 chim (requirement specification + code verificati...
Lợi ích của BDD Business Q: Are we building the right product? A: Executable specifications Technology Q: Are we building ...
Upcoming SlideShare
Loading in...5
×

Nhập môn BDD

3,379

Published on

1 Comment
8 Likes
Statistics
Notes
No Downloads
Views
Total Views
3,379
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
151
Comments
1
Likes
8
Embeds 0
No embeds

No notes for slide

Nhập môn BDD

  1. 1. Nhập môn BDD <ul><li>Waterfall </li></ul><ul><li>Agile </li></ul><ul><li>TDD </li></ul><ul><li>BDD </li></ul>Đào Thanh Ngọc
  2. 2. <ul><li>Q: Tại sao con gà băng qua đường? À quên tại sao lập trình viên lại viết chương trình? A: Để thoả mãn yêu cầu của khách hàng. </li></ul><ul><li>Q: Chương trình cần có test, test để làm gì? A: Để kiểm tra xem mã do lập trình viên tạo ra có lỗi hay không. </li></ul><ul><li>Q: Lập trình viên các bác chỉ được cái quanh co. Sao không kiểm tra thẳng xem chương trình có thoả mãn nhu cầu của khách hàng hay không? A: À, cái đó gọi là BDD! </li></ul>
  3. 3. Phương pháp phát triển phần mềm <ul><li>Để thanh toán project, qui trình luôn gồm 5 phần: phân tích yêu cầu, thiết kế, viết chương trình, kiểm tra, bảo trì </li></ul><ul><li>Không nhất thiết phải theo đúng thứ tự + 1 phần có thể đi qua nhiều lần </li></ul><ul><li>Tùy cách sắp xếp các phần mà cho ra phương pháp phát triển phần mềm khác nhau (← cũng là đi bộ, nhưng sắp xếp thứ tự bước đi theo kiểu Đoàn Dự thì thành ra Bát Bộ?)‏ </li></ul>
  4. 4. Waterfall <ul><li>Là phương pháp phát triển phần mềm cổ truyền, “hạ sách” (← sách lược default, không nghĩ ra cách gì khác thì sẽ dùng sách này)‏ </li></ul><ul><li>Là cách đánh tổng lực kiểu con nhà giàu, dàn hàng ngang mà càn quét toàn bộ chiến trường </li></ul>www.relativitycorp.com
  5. 5. Agile <ul><li>Là cách đánh du kích, tiết kiệm từng viên đạn, tính toán từng cân lương thực </li></ul><ul><li>Thanh toán từng phần nhỏ của chiến trường </li></ul><ul><li>Thanh toán 1 lần chưa thỏa mãn yêu cầu thì lặp lại -> vòng xoắn ốc </li></ul><ul><li>Vòng xoắn ốc của Mác: sự vật hiện tượng phát triển theo hình xoắn ốc, đến một lúc nào đó sẽ quay lại hình thức cũ nhưng ở cấp độ cao hơn </li></ul>
  6. 6. google: “xoắn ốc” Mác <ul><li>Dân nhậu sau thời gian hiến gan và bao tử cho rượu Tây, bia lon thì nay tìm về rượu nấu, rượu ngâm, rượu dân tộc (tắc kè, bổ củi, chuối hột...)‏ </li></ul><ul><li>Giờ mà ăn bò nhúng dấm, gà quay, vịt luột, cá hấp… thì tầm thường quá. Trở về chơi lại dế chiên bột, đuông dừa, gà ăn mày, cá kèo nướng, cá lóc nướng trui… </li></ul><ul><li>Đi du lịch thì chán chê Vũng Tàu Đà Lạt giờ chỉ khoái về quê tát đìa bắt cá, hun chuột đồng, tắm sông hay hái trái cây </li></ul>
  7. 7. Agile www.woods-info.co.jp
  8. 8. Agile www.rallydev.com
  9. 9. Waterfall VS Agile <ul><li>Còn đang tranh luận: project lớn (← thế nào là lớn?) nên dùng waterfall, nhỏ nên dùng agile? </li></ul><ul><li>Watefall: bản chất là tĩnh, khó đáp ứng thay đổi yêu cầu của khách (← Có project nào mà khách không đổi ý? Project càng lớn thì càng kí hợp đồng sao cho không cho khách đổi ý miễn phí!), lấy thịt đè người </li></ul><ul><li>Agile: vì bản chất đã động nên khách “thích thì chiều”, chỉ cần dùng team nhỏ nhưng gồm tinh binh (senior developer) có responsetiveness (phản ứng với phản hồi từ khách) cao </li></ul>
  10. 10. Waterfall VS Agile behaviour-driven.org
  11. 11. Lợi ích của Agile <ul><li>Early Return on Investment: thấy thành quả của project ngay do cứ vài ngày lại có small release, giảm thiểu được risk vì nếu có gì sai sót thì sửa được sớm </li></ul><ul><li>Increased Control: đo được ngay mức độ hiệu quả của công việc, thấy tiến triển chậm thì chuyển hướng ngay </li></ul><ul><li>Responsiveness to Change: team được trang bị lí thuyết và công cụ để đối phó với thay đổi </li></ul>
  12. 12. Agile và offshore <ul><li>Agile cung cấp nhiều mẹo (practices)‏ </li></ul><ul><li>Mẹo khó dùng cho offshore: khách và lập trình viên ngồi chung phòng (← giải quyết phần nào bằng BSE)‏ </li></ul><ul><li>Mẹo dùng được: TDD/BDD, dùng nhóm nhỏ tinh binh, small automated integrated release... </li></ul>
  13. 13. Agile và test <ul><li>Test tự động là yếu tố sống còn của agile, trong vòng xoắn ốc luôn phải có test! </li></ul><ul><li>Lí do: để có thể tự tin sửa mã chương trình, đảm bảo sau khi thay đổi nếu phát sinh bug thì phát hiện và sửa được ngay, phải có test tự động! </li></ul>
  14. 14. TDD, BDD là gì? Cộng sản Cuba Trung Quốc Việt Nam ... Agile TDD (Test Driven Development)‏ BDD (Behavior Driven Development)‏ ... Ý tưởng (tập hợp rất nhiều mẹo vặt)‏ Thực hiện cụ thể (thực hiện tập hợp con các mẹo vặt)‏
  15. 15. TDD = BDD <ul><li>Một cách chặt chẽ: 2 cái là 1 </li></ul><ul><li>Là design hơn là test, test chỉ là hệ quả (hiểu lầm thường gặp: TDD = BDD = test first)‏ </li></ul><ul><li>Design process </li></ul><ul><li>Requirements Capturing </li></ul><ul><li>Behavior Specification </li></ul><ul><li>Regression Test Suite </li></ul>
  16. 16. TDD = BDD <ul><li>(1) Đối với từng phần của chương trình, thay vì bộp cái coding chi tiết ngay, tạo khung trước (ví dụ: chỉ viết tên hàm, thân hàm bỏ trống)‏ </li></ul><ul><li>(2) Viết test cho khung này một cách khá đầy đủ xong </li></ul><ul><li>(3) Rồi mới đắp dần dần mã vào khung sao cho pass lần lượt tất cả test </li></ul><ul><li>-> (1) và (2) có tác dụng phân tích yêu cầu và thiết kế chương trình </li></ul>
  17. 17. TDD VS BDD <ul><li>Một cách thiếu chặt chẽ: </li></ul><ul><li>BDD = functional test = interface/specification test = lôi tất cả yêu cầu của khách ra để thử nghiệm </li></ul><ul><li>TDD = unit test = implementation test = lôi tất cả method của tất cả class (= unit) ra để thử nghiệm </li></ul>Unit test Functional test
  18. 18. TDD VS BDD <ul><li>BDD là cách diễn đạt dễ hiểu hơn TDD (“lựa lời mà nói cho vừa lòng nhau”)‏: TDD = assert, BDD = should </li></ul><ul><li>TDD = viết test để test mã chạy có đúng không, BDD = viết test để (1) nêu ra requirement và (2) test mã có thực hiện đúng requirement không </li></ul><ul><li>Ở (2)‏ </li></ul><ul><ul><li>TDD: nhìn test thấy code (← LTV tự sướng)‏ </li></ul></ul><ul><ul><li>BDD: nhìn test thấy yêu cầu (← thỏa mãn khách)‏ </li></ul></ul><ul><ul><li>TDD = verification, BDD = specification </li></ul></ul>
  19. 19. Vấn đề của TDD <ul><li>Lập trình viên cằn nhằn: </li></ul><ul><ul><li>Có chút xíu mã, viết test làm quách gì? </li></ul></ul><ul><li>Cấp quản lí cằn nhằn: </li></ul><ul><ul><li>Viết trước thành ra viết thừa, phí thời gian? </li></ul></ul><ul><li>-> Nguồn gốc vấn đề: </li></ul><ul><li>Dễ gây nhầm lẫn giữa test first và test driven, không nói rõ mục đích TDD là để design hơn là test </li></ul><ul><li>Thiếu tính chỉ dẫn (intuitive, ← D thứ 1)‏ </li></ul>
  20. 20. Vấn đề của TDD <ul><li>Tính chỉ dẫn: </li></ul><ul><li>Bắt đầu từ đâu? </li></ul><ul><li>Cần test cái gì?  </li></ul><ul><li>Không cần test cái gì? </li></ul><ul><li>Trong 1 test, cần test những gì? </li></ul><ul><li>Đặt tên test là gì? </li></ul>
  21. 21. BDD giải quyết vấn đề của TDD <ul><li>Làm rõ mục đích: TDD/BDD = spec first (design, documentation), chứ không phải test first‏ (verification)‏ </li></ul><ul><li>Test = specification = kết quả của phân tích yêu cầu, định nghĩa chương trình phải đáp ứng những yêu cầu gì ~ thiết kế </li></ul><ul><li>Bao giờ cũng phải phân tích nhu cầu trước -> BDD đến một cách tự nhiên ngay từ giai đoạn đầu của project </li></ul><ul><li>Có tính chỉ dẫn (học thực hành cụ thể sẽ rõ)‏ </li></ul>
  22. 22. Lợi ích của BDD <ul><li>Các lợi ích của Agile </li></ul><ul><li>1 phát 2 chim (requirement specification + code verification)‏: có spec rõ ràng thì viết mã được ngay, mã viết xong khỏi test (vì đã viết xong test!)‏ </li></ul><ul><li>Nương theo yêu cầu của khách để viết test, nên không test thừa (như TDD) hay thiếu </li></ul><ul><li>Qui trình phát triển (← D thứ 2, level của công ty xác định bởi cái này) hình thành một cách tự nhiên, xuất phát từ nhu cầu (← D thứ 1)‏ </li></ul>
  23. 23. Lợi ích của BDD Business Q: Are we building the right product? A: Executable specifications Technology Q: Are we building the product right? A: Automated tests
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×