Недавно я занимался разработкой на основе тестов (TDD), и это оказало замечательное влияние на результаты моей разработки и устойчивость моей кодовой базы. Я хотел бы распространить этот подход на некоторые виды рендеринга, которые я выполняю в OpenGL, но я не смог найти ни одного хорошего подхода к этому.
Я начну с конкретного примера, чтобы мы знали, какие вещи я хочу проверить; Допустим, я хочу создать единичный куб, который вращается вокруг некоторой оси, и хочу, чтобы при некотором количестве кадров каждый кадр отображался правильно.
Как я могу создать автоматизированный тест для этого? Предпочтительно, я бы даже смог написать тестовый пример перед написанием любого кода для рендеринга куба (в соответствии с обычной практикой TDD). Среди многих других вещей, я бы хотел убедиться, что размер, местоположение и ориентация куба исправить в каждом отображаемом кадре. Я даже хочу убедиться, что уравнения освещения в моих шейдерах правильны в каждом кадре.
Единственный отдаленно полезный подход к этому, с которым я столкнулся, включает сравнение визуализированного вывода с эталонным выводом, что, как правило, исключает практику TDD и является очень громоздким.
Я мог бы продолжить о других желаемых требованиях, но я боюсь, что те, которые я перечислил, уже недосягаемы.
Ответы:
Это похоже на хорошее применение инфраструктуры проверочных испытаний или что-то в этом роде.
Как указано в комментариях, у вас все еще будет проблема с ложными срабатываниями, если вам случится утвердить неверный вывод, но это как минимум покажет вам, когда вывод значительно изменился.
Поскольку вы используете OpenGL, я предполагаю, что одобрения не будут работать для вас напрямую, но идея обоснована. Просто проверьте хеш файла и, если он отличается, покажите ошибку в соответствующем средстве просмотра различий (например, в программе различий изображений). Если вы одобряете новую версию, обновите «утвержденный» файл, чтобы он соответствовал новому результату.
источник
Я не в игровом бизнесе, поэтому, пожалуйста, имейте в виду любое потенциальное глупое и наивное восприятие
Для меня написание тестов, которые сравнивают полностью визуализированные изображения, на самом деле не модульные тесты, а полные интеграционные тесты, потому что для успешного выполнения теста все должно работать нормально.
Как насчет промежуточного слоя, где вы можете проверить, что все в порядке? Мне на ум приходят две вещи:
Не рисуйте напрямую, но выдайте поток команд, который превращается в вызовы рендеринга по пути вниз. Поток команд можно проверить на правильность. Это не сквозной тест, но вам нужны юнит- тесты, а не полные интеграционные тесты.
Это действительно вариант 1. Оберните OpenGL, перехватите все вызовы, разделите его на то, что вы действительно хотите протестировать, и проверьте, совпадает ли вывод. Оболочка OpenGL может выполнить проверку сама, если она правильно настроена, и превращается в макет .
источник
Проблема в том, что 3d-движкам не требуется выводить точное изображение побитно. Некоторое отклонение допустимо, пока вызванные им артефакты не видны зрителю. Текстура, которая на 1% темнее, чем ожидалось, обычно не является серьезной проблемой ... обычно. При некоторых условиях это может быть визуальный артефакт. И вот в чем проблема: по автоматизированному тесту сложно судить, какие артефакты будут замечены зрителем, а какие нет. Тем не менее, автоматизированные тесты могут использоваться для простых проверок работоспособности при использовании на очень простой геометрии.
То, что вы могли бы сделать, это сделать несколько простых сцен, а затем сравнить сгенерированное изображение с эталонным рендерингом. Этот эталонный рендеринг может происходить из другого графического движка или быть более ранними скриншотами из того же движка (регрессионное тестирование).
Когда некоторые тесты не выполняются после изменения графического движка, тестировщик-человек должен сравнить вывод с эталонным изображением и самостоятельно оценить, выглядит ли новый вывод так же хорошо, как и раньше (или даже лучше). В этом случае тест следует изменить, чтобы сравнить с новыми улучшенными результатами.
Еще одна вещь, которую вы можете проверить автоматически - это требования к производительности. Одним из таких требований может быть то, что во время демоверсии (имитирующей реальную последовательность из игры) частота кадров не должна опускаться ниже 40 Fps в тестовой системе. Это то, что вы можете проверить автоматически. Что вы не можете проверить, так это то, что рендеринг удовлетворителен. Но вы можете использовать такие тесты, чтобы помешать вашим разработчикам разрабатывать игру, которая выглядит превосходно, но не работает должным образом на любой доступной системе в течение нескольких лет после запуска (привет Crytek).
источник