Vì vậy, bạn đã nghe nó nhiều lần từ những người không thực sự hiểu các giá trị của thử nghiệm. Chỉ cần bắt đầu mọi thứ, tôi là người theo dõi Agile và Thử nghiệm ...
Gần đây tôi đã có một cuộc thảo luận về việc thực hiện TDD trên một sản phẩm viết lại trong đó nhóm hiện tại không thực hành thử nghiệm đơn vị ở bất kỳ cấp độ nào và có lẽ chưa bao giờ nghe về kỹ thuật tiêm phụ thuộc hoặc mẫu / thiết kế thử nghiệm, v.v. (chúng tôi thậm chí sẽ không nhận được vào để làm sạch mã).
Bây giờ, tôi hoàn toàn chịu trách nhiệm viết lại sản phẩm này và tôi được bảo rằng việc thử nó theo kiểu TDD, sẽ chỉ khiến nó trở thành cơn ác mộng bảo trì và không thể duy trì cho đội. Hơn nữa, vì đây là một ứng dụng ngoại vi (không dựa trên web), việc thêm các bài kiểm tra là vô nghĩa, vì ổ đĩa kinh doanh thay đổi (theo những thay đổi có nghĩa là cải tiến tất nhiên), các thử nghiệm sẽ trở nên lỗi thời, các nhà phát triển khác đã đến dự án trong tương lai sẽ không duy trì chúng và trở thành gánh nặng cho họ sửa chữa, v.v.
Tôi có thể hiểu rằng TDD trong một nhóm hiện không có bất kỳ trải nghiệm thử nghiệm nào nghe có vẻ không tốt, nhưng lập luận của tôi trong trường hợp này là tôi có thể dạy thực hành cho những người xung quanh, nhưng hơn nữa, tôi biết rằng TDD tạo ra TỐT HƠN phần mềm. Ngay cả khi tôi sản xuất phần mềm bằng TDD và vứt bỏ tất cả các bài kiểm tra khi giao nó cho một nhóm bảo trì, chắc chắn đó sẽ là một cách tiếp cận tốt hơn so với việc không sử dụng TDD ngay từ đầu?
Tôi đã bị bắn hạ vì tôi đã đề cập đến việc thực hiện TDD trên hầu hết các dự án cho một nhóm chưa bao giờ nghe nói về nó. Ý nghĩ về "giao diện" và các nhà xây dựng DI trông lạ lùng làm họ sợ ...
Ai đó có thể vui lòng giúp tôi trong một cuộc trò chuyện rất ngắn về việc cố gắng bán TDD và cách tiếp cận của tôi với mọi người không? Tôi thường có một cửa sổ tranh luận rất ngắn trước khi quỳ xuống trước công ty / nhóm.