Tôi vừa mua The Art of Unit Testing từ Amazon. Tôi khá nghiêm túc về việc hiểu TDD, vì vậy hãy yên tâm rằng đây là một câu hỏi thực sự.Cố gắng tự tin vào những lợi ích của TDD
Nhưng tôi cảm thấy mình liên tục tìm kiếm sự biện minh để từ bỏ nó.
Tôi sẽ đóng vai người bảo vệ ma quỷ ở đây và cố gắng hạ thấp lợi ích của TDD với hy vọng ai đó có thể chứng minh tôi sai và giúp tôi tự tin hơn về đức tính của mình. Tôi nghĩ rằng tôi đang thiếu một cái gì đó, nhưng tôi không thể tìm ra những gì.
1. TDD để giảm lỗi
này often-cited blog post nói rằng các xét nghiệm đơn vị là các công cụ thiết kế và không cho lỗi đánh bắt:
Theo kinh nghiệm của tôi, kiểm tra đơn vị không phải là một cách hiệu quả để tìm lỗi hoặc phát hiện hồi quy.
...
TDD là một cách mạnh mẽ của thiết kế thành phần phần mềm (“đơn vị”) tương tác để hành vi của họ được xác định thông qua kiểm tra đơn vị. Đó là tất cả!
Làm cho tinh thần. Các trường hợp cạnh vẫn luôn ở đó, và bạn sẽ chỉ tìm thấy các lỗi bề ngoài - đó là những lỗi mà bạn sẽ tìm thấy ngay sau khi bạn chạy ứng dụng của mình. Bạn vẫn cần phải làm thử nghiệm tích hợp thích hợp sau khi bạn đã hoàn thành việc xây dựng một phần mềm tốt cho phần mềm của mình.
Đủ công bằng, giảm lỗi không phải là điều duy nhất TDD có nghĩa vụ trợ giúp.
2. TDD như một mô hình thiết kế
Đây có lẽ là một lớn. TDD là một mô hình thiết kế giúp bạn (hoặc buộc bạn) làm cho mã của bạn nhiều hơn composable.
Nhưng khả năng tương thích là chất lượng có thể thực hiện được nhiều lần; ví dụ, kiểu lập trình chức năng, làm cho mã hoàn toàn tương thích. Tất nhiên, rất khó để viết một ứng dụng quy mô lớn hoàn toàn theo phong cách chức năng, nhưng có một số mẫu thỏa hiệp mà bạn có thể làm theo để duy trì khả năng tổng hợp.
Nếu bạn bắt đầu với một thiết kế chức năng cao mô-đun, và sau đó cẩn thận thêm trạng thái và IO vào mã của bạn khi cần thiết, bạn sẽ kết thúc với các mẫu tương tự mà TDD khuyến khích. Ví dụ, để thực thi logic nghiệp vụ trên cơ sở dữ liệu, mã IO có thể bị cô lập trong một hàm thực hiện các tác vụ "monadic" truy cập cơ sở dữ liệu và chuyển nó làm đối số cho hàm chịu trách nhiệm về logic nghiệp vụ . Đó sẽ là cách chức năng để làm điều đó.
Tất nhiên, đây là một chút khó khăn, vì vậy thay vào đó, chúng ta có thể ném một tập hợp con của mã IO cơ sở dữ liệu vào một lớp và cung cấp cho đối tượng chứa logic nghiệp vụ liên quan. Đó là điều tương tự, một sự thích nghi của cách thức hoạt động của việc làm, và nó được gọi là mô hình kho lưu trữ.
Tôi biết điều này có thể sẽ khiến tôi trở nên khá tệ, nhưng thường thì tôi không thể không cảm thấy TDD chỉ bù đắp cho một số thói quen xấu mà OOP có thể khuyến khích - những thứ có thể tránh với một chút cảm hứng từ phong cách chức năng.
3. TDD như tài liệu
TDD được cho là đóng vai trò như tài liệu hướng dẫn, nhưng nó chỉ đóng vai trò như tài liệu hướng dẫn cho đồng nghiệp; người tiêu dùng vẫn yêu cầu tài liệu văn bản. Tất nhiên, một phương pháp TDD có thể phục vụ như là cơ sở cho mã mẫu, nhưng xét nghiệm thường chứa một số mức độ mocks mà không nên có trong mã mẫu, và thường khá giả tạo để chúng có thể được đánh giá cho sự bình đẳng so với kết quả mong đợi.
Một bài kiểm tra đơn vị tốt sẽ mô tả trong chữ ký phương pháp của nó hành vi chính xác đang được xác minh, và kiểm tra sẽ xác minh không nhiều hơn và không ít hơn hành vi đó.
Vì vậy, tôi muốn nói, thời gian của bạn có thể tốt hơn là chi tiêu cho việc đánh bóng tài liệu của bạn. Heck, tại sao không chỉ làm tài liệu đầu tiên kỹ lưỡng, và gọi nó là tài liệu hướng thiết kế?
4. TDD để thử nghiệm hồi quy
Nó đề cập trong đó bài trên TDD đó không phải là quá hữu ích cho việc phát hiện hồi quy. Đó là, tất nhiên, bởi vì các trường hợp cạnh không rõ ràng là những người luôn luôn lộn xộn khi bạn thay đổi một số mã.
Điều gì cũng có thể lưu ý về chủ đề đó là cơ hội tốt là hầu hết mã của bạn sẽ vẫn giữ nguyên trong một thời gian khá dài. Vì vậy, nó sẽ không có ý nghĩa hơn để viết bài kiểm tra đơn vị trên cơ sở khi cần thiết, bất cứ khi nào mã được thay đổi, giữ mã cũ và so sánh kết quả của nó với chức năng mới?
"những người có thể tránh được với một chút cảm hứng từ phong cách chức năng." Hầu như đồng ý ... TDD khuyến khích một phong cách mã hóa gần hơn với mô hình diễn viên, đó là loại nghịch đảo của phong cách chức năng (nó là một mô hình đẩy so với kéo mã hóa chức năng) – kyoryu
Thú vị ... Tôi nên nhìn vào mô hình diễn viên . Điều đó có thể giữ câu trả lời tôi đang tìm kiếm! –
Cần lưu ý rằng Alan Kay đã được trích dẫn khi nói rằng anh ta hối hận khi sử dụng thuật ngữ "hướng đối tượng" và mong muốn anh ta sẽ sử dụng "định hướng thông điệp". TDD đẩy bạn hướng tới một phong cách hướng thông điệp (đó là trái tim của mô hình diễn viên, hoặc giao tiếp các quy trình tuần tự, hoặc ...) – kyoryu