Kiểm tra mã nói chung không dễ dàng. Nếu đúng như vậy, chúng ta đã thực hiện tất cả từ lâu rồi và không thực hiện một thỏa thuận nào như vậy chỉ trong vòng 10-15 năm qua. Một trong những khó khăn lớn nhất luôn là việc xác định làm thế nào để kiểm tra mã đã được viết một cách cố kết, và được kiểm tra tốt, và có thể kiểm tra mà không phá vỡ đóng gói. Hiệu trưởng BDD đề nghị chúng tôi tập trung gần như hoàn toàn vào hành vi và theo một số cách dường như cho thấy rằng bạn không thực sự cần phải lo lắng về các chi tiết bên trong ở mức độ lớn như vậy, nhưng điều này thường có thể khiến mọi thứ khá khó kiểm tra nếu có rất nhiều phương pháp riêng thực hiện "công cụ" theo một cách rất ẩn, vì nó có thể làm tăng độ phức tạp chung của bài kiểm tra của bạn để đối phó với tất cả các kết quả có thể xảy ra ở cấp độ công khai hơn.
Mocking có thể giúp ở một mức độ nhất định, nhưng một lần nữa là khá tập trung bên ngoài. Dependency Injection cũng có thể hoạt động khá độc đáo, một lần nữa với giả hoặc kiểm tra nhân đôi, nhưng điều này cũng có thể yêu cầu bạn phơi bày các yếu tố thông qua giao diện, hoặc trực tiếp, mà bạn có thể muốn ẩn đi - điều này đặc biệt đúng nếu bạn muốn có một mức độ bảo mật hoang tưởng tốt đẹp về các lớp nhất định trong hệ thống của bạn.
Đối với tôi, bồi thẩm đoàn vẫn chưa biết liệu có nên thiết kế các lớp học của bạn để dễ kiểm tra hơn không. Điều này có thể tạo ra vấn đề nếu bạn thấy mình cần cung cấp các thử nghiệm mới trong khi duy trì mã kế thừa. Tôi chấp nhận rằng bạn sẽ có thể kiểm tra hoàn toàn mọi thứ trong một hệ thống, nhưng tôi không thích ý tưởng phơi bày - thậm chí gián tiếp - các phần bên trong riêng của một lớp, để tôi có thể viết bài kiểm tra cho chúng.
Đối với tôi, giải pháp luôn là áp dụng một cách tiếp cận khá thực tế và kết hợp một số kỹ thuật để phù hợp với từng tình huống cụ thể. Tôi sử dụng rất nhiều phép thử nhân đôi để thể hiện các đặc tính và hành vi bên trong cho các bài kiểm tra của mình. Tôi chế nhạo tất cả mọi thứ có thể được gắn vào các lớp của tôi và khi nó không ảnh hưởng đến an ninh của các lớp của tôi, tôi sẽ cung cấp một phương tiện để ghi đè hoặc tiêm các hành vi cho mục đích kiểm tra. Tôi thậm chí sẽ xem xét việc cung cấp một giao diện hướng sự kiện nhiều hơn nếu nó sẽ giúp cải thiện khả năng kiểm tra mã
Nơi tôi tìm thấy bất kỳ mã "không thể kiểm tra" nào , tôi tìm xem liệu tôi có thể cấu trúc lại để làm cho mọi thứ dễ kiểm tra hơn không. Nơi bạn có rất nhiều mã riêng đang ẩn sau các công cụ hậu trường, thường thì bạn sẽ thấy các lớp mới đang chờ được chia ra. Các lớp này có thể được sử dụng nội bộ, nhưng thường có thể được kiểm tra độc lập với các hành vi ít riêng tư hơn và thường sau đó ít lớp truy cập và độ phức tạp hơn. Tuy nhiên, một điều tôi cần tránh là viết mã sản xuất với mã kiểm tra được tích hợp sẵn. Việc tạo ra các " vấu kiểm tra " dẫn đến việc bao gồm những điều kinh khủng như vậy if testing then ..., điều đó cho thấy vấn đề kiểm tra chưa được giải mã hoàn toàn và giải quyết chưa đầy đủ.
Bạn có thể thấy hữu ích khi đọc cuốn sách Các mẫu thử nghiệm xUnit của Gerard Meszaros , bao gồm tất cả các loại công cụ này chi tiết hơn nhiều so với tôi có thể đi vào đây. Tôi có thể không làm mọi thứ anh ấy đề nghị, nhưng nó giúp làm rõ một số tình huống thử nghiệm khó khăn hơn để giải quyết. Vào cuối ngày, bạn muốn có thể đáp ứng các yêu cầu thử nghiệm của mình trong khi vẫn áp dụng các thiết kế ưa thích của mình và giúp hiểu rõ hơn về tất cả các tùy chọn để quyết định tốt hơn nơi bạn có thể cần phải thỏa hiệp.