Upload
ngoc-dao
View
3.227
Download
7
Embed Size (px)
Citation preview
Nhập môn BDD
Waterfall Agile TDD BDD
Đào Thanh Ngọc
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.
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.
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!
Phương pháp phát triển phần mềm
Để 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ì
Không nhất thiết phải theo đúng thứ tự + 1 phần có thể đi qua nhiều lần
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ộ?)
Waterfall
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)
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
www.relativitycorp.com
Agile
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
Thanh toán từng phần nhỏ của chiến trường 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 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
google: “xoắn ốc” Mác
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...)
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…
Đ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
Agile
www.woods-info.co.jp
Agile
www.rallydev.com
Waterfall VS Agile
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?
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
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
Waterfall VS Agile
behaviour-driven.org
Lợi ích của Agile
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
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
Responsiveness to Change: team được trang bị lí thuyết và công cụ để đối phó với thay đổi
Agile và offshore
Agile cung cấp nhiều mẹo (practices) 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)
Mẹo dùng được: TDD/BDD, dùng nhóm nhỏ tinh binh, small automated integrated release...
Agile và test
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!
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!
TDD, BDD là gì?
Cộng sản
Cuba
Trung Quốc
Việt Nam
...
AgileTDD (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)
TDD = BDD
Một cách chặt chẽ: 2 cái là 1 Là design hơn là test, test chỉ là hệ quả (hiểu
lầm thường gặp: TDD = BDD = test first) Design process Requirements Capturing Behavior Specification Regression Test Suite
TDD = BDD
(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)
(2) Viết test cho khung này một cách khá đầy đủ xong
(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
→ (1) và (2) có tác dụng phân tích yêu cầu và thiết kế chương trình
TDD VS BDD
Một cách thiếu chặt chẽ: BDD = functional test =
interface/specification test = lôi tất cả yêu cầu của khách ra để thử nghiệm
TDD = unit test = implementation test = lôi tất cả method của tất cả class (= unit) ra để thử nghiệm
Unit test
Functional test
TDD VS BDD
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
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
Ở (2) TDD: nhìn test thấy code (← LTV tự sướng) BDD: nhìn test thấy yêu cầu (← thỏa mãn khách) TDD = verification, BDD = specification
Vấn đề của TDD
Lập trình viên cằn nhằn: Có chút xíu mã, viết test làm quách gì?
Cấp quản lí cằn nhằn: Viết trước thành ra viết thừa, phí thời gian?
→ Nguồn gốc vấn đề: 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
Thiếu tính chỉ dẫn (intuitive, ← D thứ 1)
Vấn đề của TDD
Tính chỉ dẫn: Bắt đầu từ đâu? Cần test cái gì? Không cần test cái gì? Trong 1 test, cần test những gì? Đặt tên test là gì?
BDD giải quyết vấn đề của TDD
Làm rõ mục đích: TDD/BDD = spec first (design, documentation), chứ không phải test first (verification)
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ế
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
Có tính chỉ dẫn (học thực hành cụ thể sẽ rõ)
Lợi ích của BDD
Các lợi ích của Agile 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!)
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
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)
Lợi ích của BDD
BusinessQ: Are we building the right product?A: Executable specifications
TechnologyQ: Are we building the product right?A: Automated tests