Làm thế nào để bạn viết các bài kiểm tra cho mã phụ thuộc vào các triển khai bên ngoài cụ thể không thể bị chế giễu?

Bối cảnh: Tôi đang nghĩ đến việc cố gắng giới thiệu khái niệm kiểm tra đơn vị cho các đồng nghiệp của mình bằng cách tạo một số cho một mô-đun mà tôi đang làm việc; các yêu cầu của nó gần đây đã thay đổi và yêu cầu một số trừu tượng / tương tác hơn nên có vẻ như là một cách tốt để phát triển một bộ thử nghiệm sẽ "chứng minh" nó hoạt động mà không cần phải chọc thủ công ứng dụng.

Tuy nhiên, vấn đề là mô-đun phụ thuộc vào các yếu tố bên ngoài không thể chỉnh sửa được là PDF và XSL. Về cơ bản, tôi đọc XML từ cơ sở dữ liệu và áp dụng chuyển đổi XSL cho nó, sau đó chuyển đổi nó thành PDF bằng thư viện có tên ABCPDF. PDF này sau đó được hợp nhất với một PDF khác dựa trên một mẫu tĩnh. Tôi biết rằng tôi có thể kiểm tra XML và đảm bảo các giá trị là chính xác, nhưng nhiều lỗi và sự cố tiềm ẩn có liên quan đến hiển thị thực tế của tài liệu đã hoàn thành - ví dụ như các chi tiết nhỏ như chuỗi thời gian được bao bọc, trong đó các vùng HTML nhất định nằm trong mối quan hệ với tài liệu, v.v. Thậm chí có thể kiểm tra những điều này không (tôi nhận ra đây có thể là các thử nghiệm tích hợp hoặc .. loại thử nghiệm thứ ba có tên tôi quên [không phải thử nghiệm Chấp nhận, loại khác], và không phải đơn vị kiểm tra) vì tôi không thể, theo hiểu biết của mình, giả sử một tệp PDF dễ dàng tạo ra nó sau đó đọc lại hoặc tạo một chuỗi HTML (tức là đã chuyển đổi XML) và phân tích nó bằng tay để kiểm tra sự hiện diện của các ô trong bảng nhất định trong liên quan đến các tế bào bảng khác.

Trong tình huống như vậy, tôi chỉ nên tập trung vào các bài kiểm tra đơn vị để đảm bảo thông tin là chính xác và tôi có thể tạo PDF, hoặc hợp nhất chúng, hoặc bất cứ điều gì và dùng đến kiểm tra thủ công cho các vấn đề hiển thị thực tế?

Kiểm tra tính năng không phải đơn vị

Sử dụng các đầu vào xml đã biết, xuất PDF và thủ công (và tỉ mỉ) xác minh rằng đó là chính xác. Sau đó lưu nó làm tài liệu tham khảo.

Các thử nghiệm trong tương lai sử dụng cùng các đầu vào xml có thể thực hiện so sánh tệp nhị phân với tham chiếu.

Nếu so sánh cấp độ tệp không đạt yêu cầu, hãy hiển thị tệp PDF ở cuối bài kiểm tra và chụp ảnh màn hình, sau đó kiểm tra tự động so với ảnh chụp màn hình tham chiếu.

Thông thường trong trường hợp như thế này, bạn trừu tượng mọi thứ bạn không thể kiểm tra đằng sau một triển khai bạn có thể sử dụng với giao diện. Tôi sẽ chỉ làm một cái gì đó ngớ ngẩn như trình xây dựng PDF bởi vì điều đó có vẻ hợp lý.

public class PdfBuilder : IPdfBuilder
{
  public byte[] BuildPdf(...)
  {
    // actual untestable code here
  }
}

public interface IPdfBuilder
{
  byte[] BuildPdf(...);
}

Sau đó, bạn có thể giả định IPdfBuilder trong các thử nghiệm của mình để làm bất cứ điều gì bạn muốn. Điều này thường có nghĩa là bạn cần bắt đầu sử dụng bộ chứa IoC ( /programming/871405/why-do-i-need-an-ioc-container-as-opposed-to-st dánforward-di-code và /programming/21288/which-net-dependency-injection-frameworks-are-worth-looking-into là nơi để bắt đầu) nếu bạn không sử dụng ngay bây giờ.

Và các bài kiểm tra không phải là bài kiểm tra đơn vị thường được gọi là kiểm tra tích hợp. Các thử nghiệm tích hợp phức tạp thường không hoàn toàn xứng đáng, vì vậy bạn chỉ cần trừu tượng hóa phần đó và giảm lượng logic kinh doanh trong sự trừu tượng hóa đó để bạn có thể kiểm tra nó trong một thử nghiệm đơn vị.

Hãy cho tôi biết nếu điều này không hoàn toàn rõ ràng.

Tôi đã xây dựng một cái gì đó rất giống nhau một thời gian trước, và chỉ sử dụng các bài kiểm tra trực quan cơ bản. Kiểm tra không phải tự động, vì vậy không có gì sai khi chỉ tìm kiếm một kết quả mong đợi (rõ ràng, trong một loạt các tình huống được xác định trước). Thông thường, một bức tranh có giá trị bằng một ngàn bài kiểm tra mà hình ảnh được quan tâm . Tôi sử dụng thử nghiệm đơn vị tự động rộng rãi, nhưng tôi nghĩ rằng một số người có thể bị mất một chút khi tham gia thử nghiệm GUI hoặc bất cứ điều gì trực quan IMHO. Với một số sản phẩm nhất định, tôi nhận ra rằng phương pháp "đủ tốt" này sẽ không đủ YMMV.

Tôi sẽ có một chút lo lắng, tuy nhiên, về các ngoại ứng không thể thay đổi. Đây có thể là một dấu hiệu của khớp nối chặt chẽ, rất tốt để tránh như một quy tắc chung, nhưng tôi sẽ không suy đoán quá nhiều về mã của bạn trong vấn đề đó mà không có thêm chi tiết.