Как бы вы провели юнит-тестирование или выполнили наиболее эффективный автоматический тест графического кода для OpenGL?

Я пишу игру и сопутствующий графический движок поверх OpenGL на C ++. Я также фанат хороших процессов кодирования и автоматического тестирования. Тестирование графического кода + кажется довольно несмешивающимся, так как вывод часто только визуальный или очень сильно визуально ориентированный.

Например, представьте, что вы анализируете необработанный поток изображений, который отображается на экране побайтово - вам нужно сравнить тестовые данные, которые сложно создать / получить, и часто визуализированные изображения не идентичны уровень байтов при работе в разное время - небольшие изменения в алгоритмах полностью разрушат этот подход.

Я подумываю о создании набора визуальных юнит-тестов, в котором я могу в основном воспроизводить различные тестовые сцены, показывая такие вещи, как отображение теней, анимация и т. Д. И т. Д. Как часть CI, эти сцены будут затем отображаться в видео. файл (или, возможно, оставить его как исполняемый файл) с другими метриками. Это по-прежнему требует ручной проверки видеофайла, но по крайней мере это будет несколько автоматизировано и стандартизировано.

Как вы думаете? Я надеюсь, что есть лучшие способы?

Библиотека обработки изображений opencv делает это, сохраняя изображение и сравнивая его с эталонным изображением - она ​​имеет набор тестовых функций c ++ и макросов для обработки приблизительного соответствия изображений и т. Д.

Ваш тестовый фреймворк может рендерить свое тестовое изображение в буфер, извлекать визуализированное изображение и сравнивать его с «золотым» эталонным изображением, которое было сгенерировано ранее для этой цели.

Это не будет работать также в тех случаях, когда результаты вашего теста не должны оставаться точно такими же. Однако вы можете вычислить квадрат разности тестового и эталонного изображений и сравнить его с пороговым значением.

Возможно, вы также захотите предоставить для регистрации и проверки данных о производительности, так как основной регресс в производительности является еще одним возможным режимом сбоя.

Даже если вы не можете сравнить выходные изображения, по крайней мере, вы сможете проверить, что ваши рендеринг завершен надлежащим образом (без сбоев, длительного ожидания и т. Д. И т. Д.). Конечно, лучше найти способ проверки изображений, но даже без него вы получите что-то от тестов.