Có phải sự phát triển dựa trên thử nghiệm buộc tôi phải tuân theo RẮN?

15

Tôi nghe nhiều từ các học viên TDD rằng một trong những lợi thế của TDD là nó buộc các nhà phát triển tuân theo các nguyên tắc RẮN (Trách nhiệm đơn lẻ, đóng mở, thay thế Liskov, phân tách giao diện và đảo ngược phụ thuộc). Nhưng đối với tôi, chỉ cần viết một số bài kiểm tra (kiểm tra đơn vị là chủ yếu) để hiểu rằng điều quan trọng là phải tuân theo RẮN (và do đó tạo ra kiến trúc có thể kiểm tra được).

TDD có buộc các nhà phát triển tuân theo RẮN tích cực hơn là chỉ viết các bài kiểm tra đơn vị không?

unit-testing tdd solid

— SiberianGuy
nguồn

1

TDD chủ yếu là về việc buộc các nhà phát triển viết bài kiểm tra. Vì vậy, nếu bạn nói viết bài kiểm tra đơn vị làm cho bạn viết mã RẮN, tôi đoán rằng nói rằng TDD buộc bạn phải viết mã RẮN. Tuy nhiên, điều này chỉ dựa trên những gì bạn đã nói và không phản ánh chính xác ý kiến của tôi, mà bạn có thể thấy trong câu trả lời của tôi.

— Yam Marcovic

1

Yam: Tôi sẽ không đồng ý, TDD không phải là về việc viết bài kiểm tra đơn vị. TDD sắp sửa đưa ra một giải pháp tối thiểu và phức tạp cho vấn đề hiện tại. Các xét nghiệm chỉ là sản phẩm phụ của quy trình

— Amit Wadhwa

TDD theo định nghĩa là về viết thử nghiệm trước khi mã. Về mặt lý thuyết bạn có thể tạo ra một giải pháp tối thiểu và phức tạp ngay cả khi không có bài kiểm tra. Các bài kiểm tra chỉ đơn giản cung cấp cho bạn thông tin phản hồi và hồi quy ngay lập tức. Vì vẫn có thể tạo ra một giải pháp quá phức tạp bằng các thử nghiệm, TDD không phải là về việc tạo ra các giải pháp phức tạp tối thiểu mỗi se. Nó trái ngược với những gì bạn đã nói. Các giải pháp thanh lịch là một sản phẩm phụ của thủ tục, không phải là cách khác.

— Yam Marcovic

24

Trước hết, TDD không bắt buộc bạn phải viết mã RẮN. Bạn có thể làm TDD và tạo một mớ hỗn độn lớn nếu bạn muốn.

Tất nhiên, việc biết các nguyên tắc RẮN sẽ giúp ích, bởi vì nếu không, bạn có thể sẽ không có câu trả lời tốt cho nhiều vấn đề của mình và do đó viết mã xấu kèm theo các bài kiểm tra xấu.

Nếu bạn đã biết về các nguyên tắc RẮN, TDD sẽ khuyến khích bạn suy nghĩ về chúng và sử dụng chúng một cách tích cực.

Điều đó nói rằng, nó không nhất thiết bao gồm tất cả các chữ cái trong RẮN , nhưng nó khuyến khích và khuyến khích bạn viết ít nhất một phần mã RẮN, bởi vì nó làm cho hậu quả của việc không thực hiện ngay lập tức và gây khó chịu.

Ví dụ:

Bạn cần viết mã tách rời để bạn có thể chế giễu những gì bạn cần. Điều này hỗ trợ Nguyên tắc đảo ngược phụ thuộc .
Bạn cần viết các bài kiểm tra rõ ràng và ngắn gọn để bạn không phải thay đổi quá nhiều trong các bài kiểm tra (có thể trở thành một nguồn gây nhiễu mã lớn nếu được thực hiện theo cách khác). Điều này hỗ trợ Nguyên tắc Trách nhiệm duy nhất .
Điều này có thể được tranh luận, nhưng Nguyên tắc phân chia giao diện cho phép các lớp phụ thuộc vào các giao diện nhẹ hơn giúp việc theo dõi và hiểu dễ dàng hơn, bởi vì bạn không phải hỏi "Tại sao 5 phương thức này cũng bị chế giễu?", Hoặc thậm chí quan trọng hơn, bạn không có nhiều sự lựa chọn khi quyết định phương pháp nào để chế giễu. Điều này là tốt khi bạn không thực sự muốn xem qua toàn bộ mã của lớp trước khi bạn kiểm tra nó, và chỉ cần sử dụng thử và lỗi để có được sự hiểu biết cơ bản về cách thức hoạt động của nó.

Tuân thủ nguyên tắc Mở / Đóng cũng có thể giúp kiểm tra được viết sau mã, bởi vì nó thường cho phép bạn ghi đè các cuộc gọi dịch vụ bên ngoài trong các lớp kiểm tra xuất phát từ các lớp được kiểm tra. Trong TDD tôi tin rằng điều này không được yêu cầu như các nguyên tắc khác, nhưng tôi có thể bị nhầm lẫn.

Tuân thủ quy tắc thay thế Liskov là tuyệt vời nếu bạn muốn giảm thiểu các thay đổi cho lớp của mình để nhận một cá thể không được hỗ trợ, tình cờ thực hiện cùng một giao diện được nhập tĩnh, nhưng nó không có khả năng xảy ra trong các trường hợp kiểm tra thích hợp vì bạn nói chung sẽ không vượt qua bất kỳ thử nghiệm dưới lớp nào trong các triển khai trong thế giới thực của các phụ thuộc của nó.

Quan trọng nhất, các nguyên tắc RẮN đã được thực hiện để khuyến khích bạn viết mã sạch hơn, dễ hiểu hơn và có thể duy trì được, và TDD cũng vậy. Vì vậy, nếu bạn thực hiện TDD đúng cách và bạn chú ý đến cách mã và các bài kiểm tra của bạn trông như thế nào (và nó không quá khó vì bạn nhận được phản hồi ngay lập tức, API và tính đúng đắn), nói chung, bạn có thể bớt lo lắng về các nguyên tắc RẮN.

— Yam Marcovic
nguồn

Ngoài ra, trừ khi bạn theo dõi Mở / đóng và thay thế Liskov, các bản giả của bạn sẽ bị hỏng sau này. Vì vậy, ngay cả khi TDD có thể không giúp bạn thực thi OCP và LSP, các bài kiểm tra được tạo sẽ cho bạn biết khi bạn phá vỡ nó. Thêm một hiệu ứng của thử nghiệm nói chung, nhưng vẫn còn đáng nói.

— Jonas Schubert Erlandsson

9

Không

TDD có thể làm cho việc tuân theo các thực tiễn tốt trở nên dễ dàng hơn do việc tái cấu trúc liên tục, nhưng nó không bắt buộc bạn phải tuân theo bất kỳ nguyên tắc nào. Tất cả những gì nó làm là đảm bảo mã bạn viết được kiểm tra. Bạn có thể làm theo bất kỳ nguyên tắc nào bạn thích khi viết mã để đáp ứng bài kiểm tra; hoặc không có nguyên tắc nào cả.

— chế độ ăn kiêng
nguồn

2

Sự hiểu biết của tôi về các Nguyên tắc RẮN được mở rộng theo một mức độ lớn khi tôi bắt đầu thực hiện TDD. Ngay khi tôi bắt đầu nghĩ về cách chế nhạo các phụ thuộc, tôi nhận ra hầu như mọi thành phần trong cơ sở mã đều có một triển khai thay thế tiềm năng. Và việc kiểm tra API công khai đơn giản dễ dàng hơn nhiều.

Nó cũng cung cấp một sự hiểu biết mạnh mẽ hơn nhiều về hầu hết các mẫu thiết kế. Đặc biệt là Mô hình chiến lược.

— Heath Lilley
nguồn

0

Có : TDD chủ yếu là một kỹ thuật thiết kế tốt (và chỉ là kỹ thuật thử nghiệm thứ cấp). Nó giúp rất nhiều để đạt được các nguyên tắc vững chắc, mặc dù các ví dụ (bệnh lý) của TDD với rất nhiều mùi mã vẫn có thể.

Mối liên hệ giữa TDD và các nguyên tắc vững chắc đang bị tranh cãi (với kết luận ở trên) trong podcast hanselminute tuyệt vời này có tên "Phát triển hướng thử nghiệm là thiết kế - Lời cuối cùng trên TDD" .

— DaveFar
nguồn