Kiểm thử đơn vị trên các khung hình trực quan (đồ họa 3D)


8

Đây là một theo dõi cho câu hỏi này . Ở đó tôi đã hỏi làm thế nào để kiểm tra đơn vị khi bạn có một thư viện các thuật toán khoa học. Tôi có một vấn đề tương tự bây giờ nhưng với một dự án khác.

Tôi đang làm việc với một bản tóm tắt khung công cụ đồ họa 3D cho DirectX, OpenGl, WebGl, Silverlight, WPF và về cơ bản bất kỳ API 3D nào hiện có trên C #, được gọi là Rendering .NET . Kịch bản là như sau, dự án đang được phát triển bởi một nhóm nhỏ các đồng nghiệp của tôi, tất cả đều làm việc trong cùng một văn phòng. Chúng tôi là tất cả các nhà khoa học máy tính, không tham gia nhiều vào cộng đồng kỹ thuật phần mềm và thực tiễn. Tôi thậm chí đã có một thời gian khó thuyết phục để chuyển từ Subversion sang Git và xuất bản dự án trên Codeplex. Dự án đang trở nên lớn (khoảng 80 nghìn dòng C #) và hiện tại nó bao gồm hầu hết DirectX và OpenGl cho đến Shader Model 5.0, do đó, đây không phải là dự án của một người như mô tả trong câu hỏi được liên kết. Chúng tôi cũng muốn khuyến khích cộng đồng nguồn mở cộng tác.

Cho đến nay chúng tôi đã thử nghiệm bằng cách viết các ứng dụng nhỏ liên quan đến việc khởi tạo tất cả các thiết bị và tài nguyên, thiết lập cảnh và vẽ. Vấn đề là, tôi không biết làm thế nào để làm cho nó khác đi, ý tôi là, làm thế nào để thiết kế các trường hợp thử nghiệm nhỏ kiểm tra các tính năng cụ thể của khung, như phân bổ tài nguyên, tessname nguyên thủy, biên dịch shader, v.v., mà không phải tạo lại khởi tạo toàn bộ động cơ. Đối với một số trường hợp này, tôi có thể nghĩ về các giả lập hữu ích, nhưng nói chung, làm cách nào tôi có thể kiểm tra tính chính xác của thuật toán kết xuất khi đầu ra là trực quan (hình ảnh hoặc cảnh hoạt hình)? Ngay bây giờ, điều thông minh nhất mà chúng tôi đã đưa ra là kết xuất cảnh tương tự với trình kết xuất phần mềm, DirectX và OpenGl và so sánh chúng từng pixel theo pixel,

Vậy, phương pháp thử nghiệm "chính xác" ở đây là gì?


Bạn có thể triển khai các mức dung sai trong so sánh pixel theo pixel, nhưng đó sẽ là một trò chơi phủ định sai so với dương tính giả và bạn vẫn sẽ kiểm tra một phần việc triển khai DirectX / OpenGL, không chỉ mã của bạn (vì vậy, không thực sự kiểm tra đơn vị , mỗi se). Trong hầu hết các kịch bản "bình thường", bạn muốn giả lập API mục tiêu và đảm bảo rằng nó được gọi theo các giả định của bạn; nếu mã kết xuất của bạn đang gọi trực tiếp các API khác nhau, có lẽ bạn có thể giới thiệu lớp trung gian của riêng mình (có thể giả định), mặc dù ở mức phạt hiệu suất.
Daniel B

Tôi cũng nên nói thêm rằng tôi tin rằng câu trả lời của Doc Brown về cơ bản là chính xác, bạn nên (lý tưởng) có những phần thực sự độc lập mà bạn có thể kiểm tra một cách cô lập. Trong thực tế, nếu bạn chưa kiến ​​trúc giải pháp của mình từ đầu để kiểm tra đơn vị, thì điều này có thể khó cải thiện.
Daniel B

@DanielB: chính xác những gì tôi nghĩ khi đọc rằng 80K mã đã tồn tại. Đây là mã kế thừa - như Michael Feathers định nghĩa nó - mã không có kiểm tra. Và cuốn sách kinh điển cho loại tình huống này luôn là amazon.de/Working-Effectively-Legacy-Robert-Martin/dp/ Lỗi
Doc Brown

Câu trả lời:


8

Cách tiếp cận kiểm tra "chính xác" sẽ tách rời logic vẽ của bạn khỏi các cuộc gọi DirectX hoặc OpenGL, do đó bạn có thể giả lập cái sau (và như một trường hợp sử dụng khác, sử dụng cùng logic kinh doanh cho DirectX hoặc OpenGL).

Bạn không muốn kiểm tra xem DirectX hay OpenGL có hoạt động chính xác không - đó là công việc của Microsoft. Bạn cũng muốn mã khởi tạo thiết bị của mình chỉ được viết và kiểm tra một lần (và sau đó được sử dụng lại), do đó, kiểm tra thủ công phần đó phải có giá cả phải chăng. Nếu bạn cũng muốn kiểm tra phần đó một cách tự động, hãy sử dụng phương pháp pixel-by-pixel của bạn, nhưng với bản vẽ thử nghiệm rất đơn giản. Do đó, tập trung vào việc viết các bài kiểm tra hồi quy tự động cho logic vẽ tách rời của bạn, điều đó sẽ mang lại cho bạn lợi ích cao nhất.

Vì vậy, toàn bộ ý tưởng là chia mã của bạn thành các thành phần thực sự độc lập - việc khởi tạo DirectX của bạn không nên được kết hợp với logic vẽ và logic vẽ không nên phụ thuộc vào DirectX - điều này làm cho chương trình của bạn có thể kiểm tra được.

EDIT: tìm thấy bài đăng cũ này trong các bài kiểm tra đơn vị cho mã OpenGL, chỉ có một vài câu trả lời, nhưng có lẽ nó sẽ mang lại một số hiểu biết bổ sung.


Dường như cách tiếp cận này sẽ không bao gồm một phần lớn những gì thư viện này hướng tới.
Kris Van Bael

@KrisVanBael: có lẽ, có lẽ không, bạn chỉ đang đoán thôi. Nhưng hãy thoải mái đưa ra một gợi ý tốt hơn cho phương pháp thử nghiệm trong trường hợp bạn đúng.
Doc Brown

Cảm ơn @DocBrown. Khung được tách rời khỏi các triển khai API cụ thể, thông qua rất nhiều giao diện và chúng tôi đang sử dụng phép nội xạ phụ thuộc ở mọi nơi để giải quyết các trình quản lý tài nguyên, trình kết xuất, trình biên dịch, và do đó, bạn có thể, tạo một lưới bằng DirectX và trực quan hóa nó OpenGL. Vì vậy, bạn nói rằng tôi nên viết một loại "triển khai phần mềm" mà chế nhạo toàn bộ khung và kiểm tra đơn vị ở đó? Có vẻ tốt đẹp. Tôi đồng ý rằng tôi không nên kiểm tra DirectX cũng không phải OpenGL, chỉ là lớp giữa của tôi.
Alejandro Piad

@AlejandroPiad: làm thế nào để ăn một con voi? Một lần cắn một lúc. Thêm các bài kiểm tra theo lộ trình phát triển của bạn, kiểm tra các phần của chương trình bạn sẽ thay đổi tiếp theo. Chương trình của bạn không được xây dựng trong một tuần và vì vậy khung thử nghiệm của bạn sẽ không được xây dựng trong thời gian đó.
Doc Brown

1
@DocBrown cảm ơn rất nhiều. Tôi nghĩ rằng tôi nhận được nó. Tôi sẽ bắt đầu chế giễu những phần quan trọng trước tiên, và thử rằng mọi thứ mới mà chúng tôi thêm vào đều được thiết kế với mục đích thử nghiệm.
Alejandro Piad
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.