Изучение OpenGL при осуществлении TDD (поблочное тестирование)
Я запустил новый игровой проект и решил изучить и использовать OpenGL для него (проект одновременно разрабатывается в Windows и Linux). В то же время я также очень интересуюсь Разработкой через тестирование и пытаюсь приложить свои максимальные усилия к записи моих модульных тестов для продвижения дизайна перед любым фактическим кодом.
Однако я думаю, что мое отсутствие знаний могло бы сбивать меня с толку, и я продолжаю врезаться в стену в попытке записать мои модульные тесты на части "рендеринга" кодовой базы. Я надеюсь, что кто-то может дать мне некоторое понимание о том, как продолжить.
Я знаю, что мне нужны к модульному тесту мои взаимодействия с OpenGL и не самим OpenGL. Единственный путь I видит, чтобы сделать, это должно абстрагировать OpenGL далеко от остальной части моего кода в некоторой степени, или путем прерывания вызовов функции OpenGL, или создав совершенно новый интерфейс класса, позволив мне создать ложную версию того класса для тестов. (Еще лучше должен был бы абстрагировать их к ряду функций некласса в отдельном пространстве имен, а не виртуальных абстракциях класса, но я не вижу, как я мог дразнить это.)
Однако, поскольку я все еще изучаю OpenGL, у меня только есть передающая идея того, на что должна быть похожей та абстракция. Например, я перенесу каждый вызов OpenGL или сгруппирую их в высокоуровневые функции на основе задач, которые будут выполнены? Тонкие обертки сделали бы немного больше, чем вызывают конкретную функцию OpenGL, таким образом, я не должен был бы тестировать их заранее, но я мог закончить с большим количеством функций для обертывания. С другой стороны, если я захожу слишком далеко другой путь и собираю в группу несколько вызовов OpenGL задачей, я чувствую, что закончу, где я запустил, имея большое тело кода с помощью OpenGL, который самого должен быть протестирован перед использованием.
Где второй план? Как я учусь использовать OpenGL, одновременно делая надлежащее поблочное тестирование заранее?
5 ответов
Правильное тестирование рендеринга не стоит усилий. Однако вы все равно можете использовать TDD для всего остального и при разработке своего приложения.
Вот отличная статья о TDD, играх и OpenGL.
Я бы предложил сделать небольшой прототип или другой небольшой побочный проект и поиграть с opengl. Это даст вам некоторое знакомство с ним. После этого создание приложения с использованием tdd станет намного проще. И вы правы в том, что вам нужно имитировать opengl, а не тестировать opengl.
Посмотрите на Какой лучший способ отладки OpenGL?; инструменты, упомянутые в ответах на этот вопрос, сделают возможным некоторую форму тестирования, особенно GLIntercept (перехватчик вызовов функций OpenGL) звучит как очень интересный вариант/стартовая точка для дальнейших исследований.
Вы не можете автоматически тестировать часть рендеринга. Для этого вам понадобится разумное существо, способное видеть и распознавать изображения. Компьютер не подходит.
Вы можете автоматически тестировать успешное создание ресурсов - VBO, текстуры, шейдеры, списки отображения - вы можете тестировать шейдеры на предмет ошибок компиляции, тестировать математическую библиотеку, вы можете обнаруживать ошибки OpenGL, но вы не можете тестировать часть рендеринга. Лучшее, что вы можете сделать, - это создать какую-то процедуру тестирования, которая будет отображать изображение (возможно, анимированное и интерактивное) и спрашивать, правильно ли оно выглядит. Тест не будет на 100% надежным - может работать на одном оборудовании, а не на другом, человек может пропустить ошибку и т. Д.
Например, должен ли я оборачивать каждый вызов OpenGL,
Нет, это не так стоило того.
или сгруппировать их в функции более высокого уровня на основе задач, которые необходимо выполнить?
Имеет смысл написать несколько вызовов / классов для создания «текстуры», «сетки», «программы шейдера», сделать что-то вроде автоматического способа получения единообразного местоположения (если вы используете шейдеры), возможно, несколько классов для автоматического освобождения ресурсов OpenGL (например, с glDelete *** или с функциями вроде glIsTexture), но это все. Обычно вы не должны вводить дополнительные абстракции / классы, если в них нет необходимости - потому что это будет лишняя работа без какой-либо выгоды.
Обращайтесь с OpenGL так же, как с базой данных. Я бы изначально начал с единого интерфейса. Со временем, когда вы добавите больше методов, вы сможете начать разбивать единый интерфейс на несколько интерфейсов.
Как уже упоминалось, вы не можете использовать стандартную библиотеку TDD для тестирования рендеринга. Но это возможно. Думайте об этом как о тестировании рендеринга HTML в веб-клиенте. Когда я пишу свой HTML, я не использую TDD Firefox или Internet Explorer.