Thường thì lợi ích của việc sử dụng TDD được coi là lợi ích 'dài hạn' - mã tổng thể sẽ có cấu trúc tốt hơn, dễ kiểm tra hơn, ít lỗi hơn được báo cáo bởi khách hàng, v.v.
Tuy nhiên, lợi ích ngắn hạn của việc sử dụng TDD ở đâu? Có cái nào thực sự có thể đo được và dễ dàng đo lường không?
Có quan trọng để có một lợi ích ngắn hạn rõ ràng (hoặc thậm chí không rõ ràng bằng định lượng) hay không, nếu lợi ích dài hạn có thể đo lường được?
Câu trả lời:
Có một số lợi ích ngắn hạn đối với TDD, một số có thể đo lường được hơn những lợi ích khác. Đây là một số từ đỉnh đầu của tôi:
Làm sạch mã, tuân theo các nguyên tắc RẮN RẮN tốt . Đó là nếu bạn giữ các bài kiểm tra của mình sạch như mã của bạn và tránh mã kiểm tra lai bẩn , mã sẽ có xu hướng tuân theo RẮN. Mã sạch sẽ dễ đọc hơn và dễ dàng hơn để duy trì mã của bạn từ đầu. Man giờ được lưu trong quá trình bảo trì, nhưng khôn ngoan ngắn hạn: bạn sẽ nhận được mã sạch nhanh hơn (vì bạn có một số bài kiểm tra để sao lưu).
Kiểm tra hồi quy từ đầu; bạn đã phá vỡ nó, bạn sẽ biết về nó sớm. Được hỗ trợ bởi một máy chủ CI, điều này sẽ giúp bạn tiết kiệm một ít tóc. Người đàn ông mất hàng giờ để sửa một lỗi đã được hồi quy mà bạn sẽ phát hiện sớm mà không cần kiểm tra nhưng thật khó để nói rằng đó là rất nhiều giờ.
Cho phép tái cấu trúc được thực hiện mà không cần quá nhiều phỏng đoán. Nếu bạn đã hoàn thành một bộ kiểm thử cho một lớp, việc tái cấu trúc nó (như trích xuất các phương thức, sử dụng các cấu trúc dữ liệu khác, trích xuất các lớp) sẽ dễ dàng vì bạn đã xác định các kiểm tra từ đầu. Điều gì sẽ mất nhiều ngày để tái cấu trúc một lớp sẽ mất ít hơn một lớp; và bạn có thể làm điều đó ngay lập tức nếu bạn đã thực hiện các bài kiểm tra trước đó.
Thiết kế điều khiển thử nghiệm cho phép bạn sửa lỗi sao chép mã sớm. Ít nhất là nếu bạn là lập trình viên quan sát; bởi vì thử nghiệm với mã trùng lặp (cả trong mã thử nghiệm và mã sản xuất) nhanh chóng trở thành một nhiệm vụ buồn tẻ. Bạn càng thông minh hơn với mã kiểm tra của mình, nó sẽ càng tốt hơn. Ít mã hơn, ít rắc rối hơn, tiết kiệm nhiều giờ hơn.
EDIT Cũng được thêm bởi Frank Shearar, mà tôi tình cờ đồng ý:
Tại bất kỳ thời điểm nào bạn có mã làm việc (ngoại trừ trường hợp thử nghiệm mà bạn hiện đang làm việc).
Phát hiện lỗi hoặc thiết kế sớm thông qua TDD thực sự là vô giá và rất khó để đo lường bạn tiết kiệm được bao nhiêu trong thời gian làm việc; mặc dù một cách sẽ là tính số giờ bạn đã dành cho việc xử lý các vấn đề thiết kế muộn trong quá trình phát triển. Với các bài kiểm tra đơn vị, một tập hợp con mã của bạn có thể được thực hiện thông qua các bài kiểm tra của bạn mà không phải chạy ứng dụng hoặc hệ thống thực tế của bạn. Bằng cách đó, bạn có thể đảm bảo với chính mình thông qua TDD rằng một số phần của chương trình của bạn đang hoạt động ngay bây giờ , mặc dù nó có thể không được nối với thực tế vào lúc này.
Trong ngắn hạn, bạn có nghĩa là các dự án nhỏ, hoặc bạn có nghĩa là những ngày đầu của một dự án?
Tôi tin tưởng rằng việc kiểm tra được tích hợp trong khi đặt nền tảng sớm sẽ trả cổ tức ngay lập tức vì bạn đã xác minh các trụ cột mà toàn bộ phần còn lại của dự án sẽ đứng. Tôi có xu hướng thiết kế từ trên xuống và thực hiện từ dưới lên để điều này có ý nghĩa đối với cách làm việc của tôi.
Nếu bây giờ bạn bắt gặp một sự mâu thuẫn, công việc của bạn đã tự trả tiền bằng cách không phải gỡ lỗi một chương trình phức tạp hơn sau này.
Thêm vào đó, dự án của bạn đã được thiết lập để thử nghiệm và bạn sẽ không phải cấu trúc lại một giàn khoan sau này.
Một lợi ích rất ngắn hạn mà tôi tìm thấy từ TDD là tôi không cần phải tập trung quá nhiều vào những gì tôi đang cố gắng đạt được.
Nếu tôi bị gián đoạn từ công việc của mình, không có TDD, sẽ mất vài phút để tự nhắc nhở bản thân mình khi tôi trở lại nhiệm vụ.
Với TDD tôi chỉ cần chạy thử nghiệm xem cái nào thất bại và ngay lập tức tôi biết mình đang cố gắng đạt được điều gì. Tôi làm việc nhanh hơn với ít đau não hơn.