Theo tôi, những gì bạn đang mô tả như là một quy trình công việc không phải là tinh thần của TDD.
Bản tóm tắt của cuốn sách Kent Becks trên Amazon nói:
Rất đơn giản, phát triển dựa trên thử nghiệm có nghĩa là để loại bỏ nỗi sợ hãi trong phát triển ứng dụng.Trong khi một số nỗi sợ là lành mạnh (thường được xem là một lương tâm nói với các lập trình viên "hãy cẩn thận!"), Tác giả tin rằng các sản phẩm phụ của nỗi sợ hãi bao gồm các lập trình viên khó tính, cục cằn và không truyền thông, không thể tiếp thu những lời chỉ trích mang tính xây dựng. Khi các nhóm lập trình mua vào TDD, họ thấy ngay kết quả tích cực. Họ loại bỏ nỗi sợ liên quan đến công việc của họ, và được trang bị tốt hơn để giải quyết những thách thức khó khăn mà họ phải đối mặt. TDD loại bỏ các đặc điểm dự kiến, nó dạy các lập trình viên giao tiếp và nó khuyến khích các thành viên trong nhóm tìm kiếm những lời chỉ trích. Nói tóm lại, tiền đề đằng sau TDD là mã cần được kiểm tra và tái cấu trúc liên tục.
TDD thực hành
Kiểm thử tự động chính thức, đặc biệt là Kiểm thử đơn vị mọi phương thức của mọi lớp đều tệ như một mô hình chống và không kiểm tra bất cứ điều gì. Có một sự cân bằng để có được. Bạn đang viết bài kiểm tra đơn vị cho mọi setXXX/getXXXphương pháp, chúng cũng là phương pháp!
Các xét nghiệm cũng có thể giúp tiết kiệm thời gian và tiền bạc, nhưng đừng quên rằng chúng tốn thời gian và tiền bạc để phát triển và chúng là mã, vì vậy chúng tốn thời gian và tiền bạc để duy trì. Nếu họ teo vì thiếu bảo trì thì họ trở thành một trách nhiệm nhiều hơn là một lợi ích.
Giống như mọi thứ như thế này, có một sự cân bằng không thể được xác định bởi bất kỳ ai trừ chính bạn. Bất kỳ giáo điều nào, có lẽ là sai nhiều hơn mà đúng.
Một số liệu tốt là mã quan trọng đối với logic nghiệp vụ và có thể sửa đổi thường xuyên dựa trên các yêu cầu thay đổi. Những thứ đó cần các bài kiểm tra chính thức được tự động hóa, đó sẽ là một khoản đầu tư lớn.
Bạn sẽ rất khó khăn để tìm thấy nhiều cửa hàng chuyên nghiệp hoạt động theo cách này. Nó chỉ không có ý nghĩa kinh doanh để chi tiền thử nghiệm những thứ sẽ cho tất cả các mục đích thực tế không bao giờ thay đổi sau khi thử nghiệm khói đơn giản được hình thành trước. Viết các bài kiểm tra đơn vị tự động chính thức cho .getXXX/.setXXXcác phương pháp là một ví dụ điển hình cho việc này, hoàn toàn lãng phí thời gian.
Bây giờ là hai thập kỷ kể từ khi chỉ ra rằng thử nghiệm chương trình có thể chứng minh một cách thuyết phục sự hiện diện của lỗi, nhưng không bao giờ có thể chứng minh sự vắng mặt của chúng. Sau khi trích dẫn lời nhận xét được công bố rộng rãi này, kỹ sư phần mềm trở lại trật tự trong ngày và tiếp tục hoàn thiện các chiến lược thử nghiệm của mình, giống như nhà giả kim của yore, người tiếp tục tinh chỉnh các tinh chế chrysocosmic của mình.
- Edsger W. Djikstra . (Được viết vào năm 1988, vì vậy giờ đã gần 4,5 thập kỷ.)
Xem thêm câu trả lời này .