Có phải sau TDD chắc chắn sẽ dẫn đến DI?

Tôi đã học cách thực hiện Phát triển dựa trên thử nghiệm (TDD), Tiêm phụ thuộc (DI) và Đảo ngược điều khiển (IoC) cùng một lúc. Khi tôi viết mã bằng TDD, tôi luôn luôn sử dụng DI trong các hàm tạo của lớp. Tôi tự hỏi liệu điều này là do cách tôi học làm TDD, hay đây là tác dụng phụ tự nhiên của TDD.

Vì vậy, câu hỏi của tôi là: Việc theo dõi hiệu trưởng TDD và viết bài kiểm tra đơn vị không phụ thuộc vào các dịch vụ bên ngoài chắc chắn sẽ dẫn đến DI?

Việc theo dõi TDD và viết bài kiểm tra đơn vị không phụ thuộc vào cơ sở dữ liệu hoặc dịch vụ bên ngoài chắc chắn sẽ dẫn đến DI?

Đối với định nghĩa rộng của DI, có. Các lớp học không tồn tại trong một vắc-xin, vì vậy họ cần phải có sự phụ thuộc của họ bằng cách nào đó. Đôi khi chỉ cần cung cấp một giá trị là tốt. Đôi khi bạn cần cung cấp một giả trong hàm tạo. Đôi khi thông qua các container IoC. Đôi khi thông qua truy cập thử nghiệm riêng tư. Tất cả đều tiêm một số thứ kiểm tra vào lớp để nó có thể hoạt động độc lập.

Đối với những người đã biết về DI, nhưng chưa bao giờ nhìn thấy điểm này, tôi nghĩ thử nghiệm đơn vị sẽ gần như luôn luôn dẫn đến việc sử dụng DI.

Nếu bạn không biết về DI và đang cố gắng viết bài kiểm tra đơn vị, một số người sẽ tự nhiên phát minh lại DI, một số người sẽ thất vọng và cuối cùng phát hiện ra DI thông qua nghiên cứu, nhưng bạn sẽ ngạc nhiên về việc nó thường không xảy ra với ai đó rằng có thể có một cách tốt hơn để kiến ​​trúc sư phần mềm của họ để làm cho việc kiểm tra đơn vị dễ dàng hơn. Những người viết ra kiểm tra đơn vị là khó khăn và bỏ cuộc.

Kiểm tra đơn vị sẽ dẫn đến DI (vì nó buộc bạn phải tạo các đơn vị ghép lỏng lẻo). TDD không nhất thiết, vì TDD cũng có thể được sử dụng để tạo các bài kiểm tra từng lớp, thay vì các bài kiểm tra đơn vị "nguyên văn". Xem bài viết này

http://stephenwalther.com/archive/2009/04/11/tdd-tests-are-not-unit-tests.aspx

cho một lời giải thích về sự khác biệt.

Có và không: TDD dẫn đến việc viết mã có cấu trúc tốt, chính nó dẫn đến DI.

Điều đó có nghĩa là TDD thường gửi cho bạn đúng cách liên quan đến đóng gói, SRP và tái sử dụng. Đây không chỉ là việc thực hiện một số thử nghiệm làm tròn mã của bạn: đó là về việc sử dụng các thử nghiệm đó để đưa ra một thiết kế tốt hơn. Nếu một đối tượng tạo ra các phụ thuộc của riêng nó, thì nó sống trong một bối cảnh cụ thể trong một ứng dụng cụ thể và có khả năng được đưa vào ứng dụng ở mức độ lớn hơn. DI là một điều tốt, không chỉ từ quan điểm thử nghiệm, mà còn từ quan điểm chất lượng mã.

Như đã chỉ ra trong các câu trả lời khác, TDD không yêu cầu kiểm tra đơn vị . Bạn cũng có thể viết các bài kiểm tra tích hợp / chức năng trong khi thực hiện TDD. Trong một số cách để áp dụng TDD, việc tạo các bài kiểm tra đơn vị sẽ là cách "giả mạo cho đến khi bạn thực hiện" (xem cuốn sách của Kent Beck để biết chi tiết).

Đối với "TDD chắc chắn dẫn đến DI", chắc chắn là không. Những gì người ta cần khi viết bài kiểm tra đơn vị là cách ly đơn vị đang được kiểm tra khỏi việc thực hiện các phụ thuộc bên ngoài của nó. Và điều này có thể được thực hiện dễ dàng như có hoặc không có DI. Cách tốt nhất, có lẽ, là sử dụng một công cụ cách ly / chế giễu thích hợp.