XP – Test Driven Development
- Date 18/04/2020
Nếu bạn nhìn vào cách các programmer viết code theo cách phát triển truyền thống, bạn sẽ thấy rằng họ thường chọn một phần của chương trình để làm, viết code, cố gắng biên dịch code, sửa tất cả các lỗi biên dịch, duyệt code trong một trình gỡ lỗi, và sau đó lặp lại chu trình. Điều này được tóm tắt trong hình vẽ.
Quá trình truyền thống này rất khác với phương pháp test-driven development (TDD). Một programmer thực hiện test-driven development trong các chu kỳ rất ngắn để xác định và tự động hóa một thử nghiệm thất bại, viết code vừa đủ để vượt qua thử nghiệm đó, sau đó làm sạch code theo bất kỳ cách cần thiết nào trước khi bắt đầu lại. Chu kỳ này được lặp lại cứ sau vài phút, thay vì sau vài giờ.
Tôi thấy thực hành test-driven development (TDD) là hết sức có giá trị. Một trong những lý do lớn nhất là đảm bảo rằng không có code chưa được kiểm tra nào được đưa vào hệ thống. Nếu tất cả code phải được viết để sao cho pass với các test đã được viết từ trước, thì chỉ như vậy cũng đủ cho chúng ta viết được code bao quát toàn bộ phạm vi cần test. Bạn có thể nghĩ rằng cách tiếp cận thử nghiệm sau khi code (kiểu truyền thống) sẽ đạt được kết quả tương tự. Tuy nhiên, tôi đã nhận thấy rằng dù cho các programmer cam kết sẽ viết bài unit test của họ ngay sau khi họ hoàn thành code xong một tính năng, họ trên thực tế thường không làm như vậy. Áp lực để bắt tay ngay vào lập trình tính năng tiếp theo có thể rất lớn. Vì vậy, các programmer có xu hướng viết các unit test cho một tập hợp con của chức năng mới hoặc đưa việc viết unit test vào danh sách những điều cần làm sau, và sau đó hóa ra điều này không bao giờ được thực hiện.
Hãy coi TDD giống như là ta chuyển công việc thiết kế trở thành một thực hành lập trình vậy. Rốt cuộc, các unit test mà một programmer viết và thứ tự chúng được viết đã hướng dẫn cho việc thiết kế và phát triển một tính năng. Một programmer sẽ không tạo ra một danh sách 50 bài unit test nhỏ và sau đó chọn ngẫu nhiên để thực hiện. Thay vào đó, mỗi thử nghiệm và trình tự thực hiện nó được chọn sao cho sự không chắc chắn (uncertainty) của tính năng được giải quyết sớm. Bằng cách này, việc lựa chọn và thực hiện các test thúc đẩy quá trình phát triển, dẫn đến một thiết kế hay ít nhất là một phần của thiết kế thực sự xuất phát từ nhu cầu của hệ thống.
Có một số tranh cãi về việc liệu thực hành TDD có thực sự dẫn đến các thiết kế vững chắc hơn hay tốt hơn không. Nhưng chắc chắn rằng TDD là rất hữu ích giúp các programmer suy nghĩ kỹ về các thiết kế của họ. Một thiết kế mà khó kiểm tra rất có thể là chỉ dấu của một cấu trúc code kém.
Một thực hành thú vị của XP là tập trung vào thử nghiệm. Trong một dự án XP, các programmer viết các bài unit test tự động và customer viết các acceptance test mà thường được tự động hóa bởi chính customer hoặc với sự trợ giúp từ các programmer. Nhiều programmer XP đã thực sự tìm thấy những lợi ích của việc thử nghiệm sớm và thường xuyên. Hơn nữa, sự kháng cự truyền thống của các programmer đối với thử nghiệm đã giảm xuống vì các unit test trong XP thường được chạy tự động khi programmer đang lập trình.
Ngoài unit test của programmer, các bài acceptance test của customer là một phần quan trọng của XP. Đối với mỗi user story, customer chịu trách nhiệm xác định một loạt các acceptance test để xác định xem user story có được phát triển phù hợp với các kỳ vọng và giả định của customer hay không. Theo nhiều khía cạnh có thể coi các acceptance test của customer là hình thức thay thế cho các tài liệu yêu cầu (URD) trong quy trình phát triển kiểu waterfall truyền thống.
Vài gợi ý thực hành
- Hãy cam kết dành ít nhất một ngày trong tuần tới để thực hiện test-driven development. Nếu bạn chưa bao giờ thực hiện TDD trước đây, bạn có thể sẽ cần phải làm việc với một programmer khác để hiểu rõ hơn. Ngay cả khi đối tác của bạn không có kinh nghiệm về TDD, việc học cùng nhau sẽ dễ dàng hơn.
- Làm quen với cách viết một unit test thất bại trước khi viết code có thể khó khăn. Vì đó là một cách làm rất khác với cách truyền thống (code trước test sau). Hãy tập hợp bốn đến tám programmer trong phòng làm việc được trang bị máy tính xách tay và máy chiếu. Chọn một programmer để bắt đầu viết code trong khi mọi người khác nhìn vào code. Tìm một unit test thất bại bạn có thể viết, và sau đó programmer viết code làm cho unit test được pass. Sau 15 phút, chuyển máy tính xách tay cho một programmer khác. Tiếp tục viết code và chuyển máy tính xách tay cho đến khi nhiệm vụ hoàn thành.
- Nếu việc thử TDD trên ứng dụng đầy đủ của bạn quá khó ngay bây giờ, hãy tìm một dự án ít quan trọng mà bạn có thể thử thực hành TDD. Chẳng hạn có thể cân nhắc thử TDD cho một dự án chuyển đổi dữ liệu mà đang bị gác lại.
Theo Mike Cohn
