2012-01-25 56 views
10

Tôi đang viết thư viện OpenGL 2D bằng Python. Mọi thứ đều tuyệt vời và codebase đang phát triển đều đặn.Làm cách nào để viết các bài kiểm tra cho thư viện đồ họa?

Bây giờ tôi muốn viết các bài kiểm tra đơn vị vì vậy tôi không vô tình mang lỗi mới trong khi sửa chữa các lỗi khác/tạo các tính năng mới. Nhưng tôi không có ý tưởng làm thế nào những người sẽ làm việc với các thư viện đồ họa.

Một số điều tôi nghĩ:

  • ảnh chụp màn hình tài liệu tham khảo thực hiện và đối chiếu với ảnh chụp màn hình được tạo tự động trong các bài kiểm tra
  • thay thế các cuộc gọi OpenGL với báo cáo khai thác gỗ và so sánh các bản ghi

Nhưng cả hai dường như một ý tưởng tồi. Cách phổ biến để kiểm tra thư viện đồ họa là gì?

+0

Hai điều bạn đã đề xuất có ý nghĩa đối với tôi, miễn là bạn chắc chắn có kết quả thực sự để so sánh. – lhf

Trả lời

3

Phương pháp tôi đã sử dụng trong quá khứ để kiểm tra mức độ thành phần là:

  • Sử dụng một nền tảng thống nhất màu, với một vài màu sắc khác nhau.
  • Sử dụng hình chữ nhật màu đồng nhất làm đối tượng đồ họa trong thử nghiệm (với một vài màu khác nhau).
  • Đặt hình chữ nhật ở những nơi đã biết nơi bạn có thể tự tính vị trí dự kiến ​​của chúng trong hình ảnh.
  • Tính cường độ dự kiến ​​của mỗi kênh của mỗi pixel (nền, nền trước hoặc hỗn hợp).
  • Nếu bạn có một kịch bản thử nghiệm mà kết quả ở các vị trí không tròn, sử dụng một tổ chức phi chính xác so sánh (ví dụ tương quan)
  • Sử dụng tính toán để tạo ra hình ảnh kết quả mong đợi.
  • So sánh hình ảnh đầu ra với hình ảnh kết quả mong đợi.
  • Nếu bạn có hiệu ứng mờ, hãy so sánh tổng cường độ thay vì cường độ rời rạc.

Như graham đã nêu, các đơn vị nội bộ có thể được kiểm tra đơn vị miễn phí từ các cuộc gọi đồ họa.

+0

Đó là những bài kiểm tra chấp nhận, và chúng rất quan trọng, nhưng bạn cũng sẽ cần các bài kiểm tra đơn vị, như Graham Reeds đã nói trong câu trả lời khác. –

+0

Đây không phải là bài kiểm tra chấp nhận, các bài kiểm tra này kiểm tra một thành phần duy nhất và là một trong hai bài kiểm tra tích hợp hoặc kiểm tra đơn vị tùy thuộc vào định nghĩa của đơn vị được kiểm tra. Nếu các thuật toán đồ họa được viết trong các trình đổ bóng hoặc trong mã OPENGL/DirectX, thì mã không phải lúc nào cũng có thể thử nghiệm riêng biệt với quá trình dựng hình đồ họa và đây là cách duy nhất để "đơn vị" kiểm tra nó. –

+0

@RadomirDopieralski Bài kiểm tra chấp nhận sẽ đảm bảo bạn có thể xem nội dung nào đó và không xem xét ** vị trí chính xác **, ** luồng trắng **, mỗi loại định dạng ** pixel **, ảnh hưởng của hiệu ứng bộ lọc và vv Kiểm tra hệ thống sẽ bao gồm ứng dụng phía trên công cụ đồ họa. –

1

Chia nhỏ hơn nữa.

Các cuộc gọi làm cho đồ họa sẽ dựa vào thuật toán - kiểm tra thuật toán.

+0

Thực ra, trong trường hợp của tôi chỉ đúng một nửa. Mặc dù có hầu như tất cả các chức năng cơ bản, tôi chỉ sử dụng một thuật toán (trong phân loại các sprites cho rendering hàng loạt) và một số thứ như các mẫu đơn. Hầu như tất cả các mã khác đều đơn giản khiến cho các cuộc gọi OpenGL có thể truy cập được. – orlp

+0

Độc thân là ác! Một hợp đồng mà tôi đã làm việc để sử dụng gần một tá trong số họ. Thực hiện thử nghiệm một cơn ác mộng. Trong C++, chúng tôi đã tạo ra một số chức năng được tạo khuôn mẫu cho phép bạn kéo vào bộ ghi log giả hoặc thực, v.v. để thực hiện kiểm tra có thể. Dunno nếu bạn có thể làm điều đó trong Python. –

Các vấn đề liên quan