Tôi đã đặt tiêu đề cho câu hỏi một cách đùa cợt bởi vì tôi chắc chắn rằng "nó phụ thuộc", nhưng tôi có một số câu hỏi cụ thể.
Làm việc trong phần mềm có nhiều lớp phụ thuộc sâu, nhóm của tôi đã quen với việc sử dụng chế độ nhạo báng khá rộng rãi để tách từng mô-đun mã khỏi các phụ thuộc bên dưới nó.
Do đó, tôi đã rất ngạc nhiên khi Roy Osherove gợi ý trong video này rằng bạn chỉ nên sử dụng chế độ chế giễu khoảng 5%. Tôi đoán rằng chúng ta đang ngồi ở đâu đó giữa 70-90%. Thỉnh thoảng tôi cũng thấy hướng dẫn tương tự khác .
Tôi nên xác định những gì tôi coi là hai loại "kiểm thử tích hợp" khác biệt đến mức chúng thực sự phải được đặt tên khác nhau: 1) Các thử nghiệm trong quá trình tích hợp nhiều mô-đun mã và 2) Thử nghiệm ngoài quy trình nói chuyện đến cơ sở dữ liệu, hệ thống tệp, dịch vụ web, v.v. Đây là loại số 1 mà tôi quan tâm, các thử nghiệm tích hợp nhiều mô-đun mã tất cả trong quá trình.
Phần lớn các hướng dẫn cộng đồng mà tôi đã đọc gợi ý rằng bạn nên ưu tiên một số lượng lớn các bài kiểm tra đơn vị hạt mịn, tách biệt và một số ít các bài kiểm tra tích hợp đầu cuối hạt thô, bởi vì các bài kiểm tra đơn vị cung cấp cho bạn phản hồi chính xác về nơi hồi quy có thể đã được tạo, nhưng các bài kiểm tra thô, rất khó cài đặt, thực sự xác minh thêm chức năng đầu cuối của hệ thống.
Vì điều này, có vẻ như cần phải sử dụng chế độ chế nhạo khá thường xuyên để cô lập các đơn vị mã riêng biệt này.
Cho một mô hình đối tượng như sau:
... Cũng xem xét rằng độ sâu phụ thuộc của ứng dụng của chúng tôi đi sâu hơn nhiều so với mức tôi có thể phù hợp với hình ảnh này, do đó có nhiều lớp N nằm giữa lớp 2-4 và lớp 5-13.
Nếu tôi muốn kiểm tra một số quyết định logic đơn giản được đưa ra ở đơn vị số 1 và nếu mọi phụ thuộc được đưa vào hàm xây dựng vào mô-đun mã phụ thuộc vào nó, thì, 2, 3 và 4 là hàm tạo được đưa vào mô-đun 1 trong hình ảnh, tôi rất muốn tiêm giả 2, 3 và 4 vào 1.
Mặt khác, tôi sẽ cần xây dựng các trường hợp cụ thể của 2, 3 và 4. Điều này có thể khó khăn hơn so với việc chỉ cần gõ thêm. Thường thì 2, 3 và 4 sẽ có các yêu cầu của nhà xây dựng có thể gây khó khăn để đáp ứng và theo biểu đồ (và theo thực tế của dự án của chúng tôi), tôi sẽ cần xây dựng các trường hợp cụ thể từ N đến 13 để đáp ứng các nhà xây dựng của 2, 3 và 4.
Tình huống này trở nên khó khăn hơn khi tôi cần 2, 3 hoặc 4 để hành xử theo một cách nào đó để tôi có thể kiểm tra quyết định logic đơn giản trong # 1. Tôi có thể cần phải hiểu và "lý luận về mặt tinh thần" về toàn bộ biểu đồ / cây đối tượng cùng một lúc để có được 2, 3 hoặc 4 để hành xử theo cách cần thiết. Việc làm myMockOfModule2.Setup (x => x.GoLeftOrRight ()) có vẻ dễ dàng hơn nhiều. Trả về (new Right ()); để kiểm tra mô-đun 1 đáp ứng như mong đợi khi mô-đun 2 bảo nó đi đúng.
Nếu tôi thử nghiệm các trường hợp cụ thể của 2 ... N ... 13 tất cả cùng nhau, các thiết lập thử nghiệm sẽ rất lớn và chủ yếu là trùng lặp. Thất bại thử nghiệm có thể không làm rất tốt việc xác định chính xác các vị trí của thất bại hồi quy. Các xét nghiệm sẽ không độc lập ( một liên kết hỗ trợ khác ).
Cấp, thường là hợp lý để thực hiện kiểm tra dựa trên trạng thái, thay vì dựa trên tương tác, của lớp dưới cùng, vì các mô-đun hiếm khi có bất kỳ sự phụ thuộc nào nữa. Nhưng có vẻ như việc chế nhạo là gần như cần thiết theo định nghĩa để cô lập bất kỳ mô-đun nào trên mức thấp nhất.
Với tất cả những điều này, bất cứ ai cũng có thể cho tôi biết những gì tôi có thể thiếu? Là đội của chúng tôi lạm dụng giả? Hoặc có lẽ có một số giả định trong hướng dẫn kiểm thử đơn vị điển hình rằng các lớp phụ thuộc trong hầu hết các ứng dụng sẽ đủ nông để kiểm tra tất cả các mô-đun mã được tích hợp với nhau (làm cho trường hợp của chúng tôi trở nên "đặc biệt")? Hoặc có lẽ khác nhau, là nhóm của chúng tôi không giới hạn bối cảnh bị ràng buộc của chúng tôi đầy đủ?
Or is there perhaps some assumption in typical unit testing guidance that the layers of dependency in most applications will be shallow enough that it is indeed reasonable to test all of the code modules integrated together (making our case "special")? <- Cái này.