Cân nhắc một người mới bắt đầu giao dịch với Dependency Injection. Chúng tôi đang phân tích hai lớp có liên quan trong NerdDinner.Tiêm phụ thuộc vào NerdDinner - thực sự kiểm tra kho lưu trữ hoặc mô hình của bạn
DinnerRepository từ ứng dụng: 
FakeDinnerRepository từ các bài kiểm tra: 
Họ thực hiện logic khác nhau, trong đó tất nhiên là cần thiết, như ý tưởng then chốt ở đây là để thực hiện IDinnerRepository và cung cấp các triển khai và thành viên riêng khác nhau.
Tôi hiểu bài kiểm tra dành cho bộ điều khiển, nhưng tôi lo ngại rằng có hai cách triển khai logic truy cập dữ liệu khác nhau. Hãy xem xét bất kỳ dự án nào sử dụng bất kỳ loại ORM, ADO.NET, SubSonic hoặc bất kỳ hương vị nào của truy cập dữ liệu bạn muốn. Có, bạn có thể thiết lập kho lưu trữ giả của mình để khớp với repo thực.
Nỗi lo lắng của tôi là theo thời gian, chi tiết triển khai trong thay đổi thực repo. Có thể lỗi đánh máy hoặc một số thay đổi chi tiết thực hiện quan trọng khác trong truy vấn . Điều này dẫn đến một sự không phù hợp tiềm năng của logic trong Mô hình giữa giả và repo thực. Sự lo lắng là việc thực hiện repo thực và kiểm tra repo được ra khỏi đồng bộ.
Câu hỏi:
- Làm thế nào bạn sẽ thử nghiệm mô hình trong trường hợp này?
- Thích hợp để kiểm tra mô hình?
- Đây có phải là vấn đề kỷ luật để đảm bảo kiểm tra của bạn theo kịp với việc thực hiện logic nghiệp vụ không?
Cảm ơn Rune. Điều đó có ý nghĩa. Tôi đoán cơ sở của câu hỏi là: bạn có nên kiểm tra quyền truy cập dữ liệu của mình không? Có vẻ như bạn đang nói 'không'. –
Đó thực sự là một trong những điều tôi đấu tranh với bản thân mình như là một TDDer bắt đầu. Cách mà tôi hiện đang hiểu nó, các xét nghiệm đơn vị của bạn nên để lại quyền truy cập dữ liệu thực tế một mình, trong khi nó là một ý tưởng tốt để có các bài kiểm tra tích hợp cũng kiểm tra rằng truy cập dữ liệu thực sự hoạt động tốt. Các bài kiểm tra tích hợp này sẽ chậm hơn, nhưng điều đó nên được chấp nhận vì chúng có thể sẽ không chạy thường xuyên như các bài kiểm tra đơn vị "thuần túy". –