Test-Driven Development - TDD
Thông thường khi phát triển hoặc update một chức năng nào đó, với cách tiếp cần truyền thống, chúng ta thường viết test case sau khi hoàn thành viết code.
TDD là phương pháp phát triển hoàn toàn trái ngược: viết test case trước khi bắt tay vào viết code
Ô thế tôi chưa viết code thì pass test case kiểu gì?
Tư tưởng của TDD đó là hay nghĩ về thiết kế của bạn trước khi viết mã nguồn. Mục tiêu của TDD là viết code sáng sủa, rõ ràng và có thể chạy test được.
The Three Laws of TDD
TDD đặt ra 3 điều luật để đảm bảo quy trình phát triển của một tính năng.
First Law: You may not write production code until you have written a failing unit test
Trước khi bắt tay vào viết production code, cần viết unit test trước và đảm bảo nó chạy fail.
Second Law: You may not write more of a unit test than is sufficient to fail, and not compiling is failing
Có thể hiểu không nên có nhiều hơn 1 fail test, hãy viết production code để pass test trước khi viết thêm một unit nào khác.
Third Law: You may not write more production code than is sufficient to pass the currently failing test
Chỉ viết production code đủ để pass test, nếu pass unit kể cả có đoạn production code đó hay không thì đoạn code đó là dư thưa và không cần thiết.
Thực hành TDD
Đọc qua về 3 điều luật thì có vẻ hơi khó hiểu, mình sẽ minh họa bằng cách áp dụng TDD vào để phát triển API đăng ký user sử dụng framework Laravel
Mình sẽ viết test case đơn giản cho chức năng này. Nội dung test đó là gửi 1 POST request tới register url với body là 1 array rỗng, mong muốn response status code 200 và trả về data với cấu trúc json.
Đây là kết quả chạy chạy test case. Kết quả fail do cấu trúc trả về không đúng định dạng. Như bạn có thể thấy, function register mình định nghĩa phía trên không hề return bất cứ data nào cả, đó là nguyên nhân dẫn tới kết quả test case fail.
Ta đã có test fail, việc tiếp theo là update production code để pass qua test fail này.
Ở đây mình chỉ thêm 1 dòng code đơn giản đó ra trả về một response có body là 1 array rỗng, mục đích là đủ để pass qua test case hiện tại. Đây là kết quả chạy test case:
Tới đây là đã đủ một chu kỳ của TDD. Để bắt đầu chu kỳ tiếp theo, chúng ta lại update test case gửi kèm data trong request và expect kết quả trả về id của user
Sau khi update test case, ta lại update production code. Cứ vậy lặp đi lặp lại các bước cho tới khi hoàn thành thức năng.
Tựu chung lại ta sẽ thực hiện theo mô hình dưới đây:
Đây là kết quả cuối cùng của mình sau khi hoàn thiện chức năng Production code:
Test case:
Trên đây là đoạn code và test case đơn giản nhất, các bạn có thể bổ sung thêm test case validate data đầu vào cho chức năng này.
Kết luận
TDD không thay thế phương pháp kiểm thử truyền thống, thay vào đó nó định nghĩa một cách thức để đảm bảo việc thực hiện các unit test một cách hiệu quả. Hiệu ứng phụ của TDD là các kiểm thử cung cấp một đặc tả hoạt động cho mã nguồn. TDD được đánh giá tin cậy trong thực tế và được nhiều lập trình viên phần mềm quan tâm và lựa chọn.