23
Nhập môn BDD Waterfall Agile TDD BDD Đào Thanh Ngọc

Nhập môn BDD

Embed Size (px)

Citation preview

Page 1: Nhập môn BDD

Nhập môn BDD

Waterfall Agile TDD BDD

Đào Thanh Ngọc

Page 2: Nhập môn BDD

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!

Page 3: Nhập môn 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ộ?)

Page 4: Nhập môn BDD

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

Page 5: Nhập môn BDD

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

Page 6: Nhập môn BDD

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

Page 7: Nhập môn BDD

Agile

www.woods-info.co.jp

Page 8: Nhập môn BDD

Agile

www.rallydev.com

Page 9: Nhập môn BDD

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

Page 10: Nhập môn BDD

Waterfall VS Agile

behaviour-driven.org

Page 11: Nhập môn BDD

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

Page 12: Nhập môn BDD

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...

Page 13: Nhập môn BDD

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!

Page 14: Nhập môn BDD

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)

Page 15: Nhập môn BDD

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

Page 16: Nhập môn BDD

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

Page 17: Nhập môn BDD

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

Page 18: Nhập môn BDD

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

Page 19: Nhập môn BDD

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)

Page 20: Nhập môn BDD

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ì?

Page 21: Nhập môn BDD

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õ)

Page 22: Nhập môn BDD

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)

Page 23: Nhập môn BDD

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