Разве мой код является действительно не тестируемым единицей?

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

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

Если вы можете получить визуализированное изображение, вы можете выполнить его модульное тестирование.

Просто визуализируйте некоторые изображения с использованием текущей кодовой базы, посмотрите, «правильно ли они выглядят» (исследуя их до пикселя, если нужно), и сохраните их для сравнения. Затем ваши модульные тесты можно сравнить с этими сохраненными изображениями и посмотреть, будет ли результат таким же.

Стоит ли это хлопот, решать вам.

Разбейте рендеринг на шаги и протестируйте, сравнивая буфер кадров для каждого шага с известными хорошими изображениями.

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

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

Если вы не можете разбить свой код на единицы, это очень сложно провести модульное тестирование. Я предполагаю, что если у вас есть трехмерные атомарные функции (скажем, преобразовать, повернуть, и спроецировать point) они должны быть легко проверяемы - создайте набор контрольных точек и проверьте, приводит ли преобразование точку туда, где она должна. Если вы можете получить доступ к 3D-коду только через ограниченный API, это будет сложно для тестирования. См. сообщения о тестируемости Миско Хевери и его руководство по тестируемости .

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

Я считаю явно пригодным для модульного тестирования код, который, очевидно, имеет место для ошибок . Примеры:

• Код для вычисления сложных математических функций или функций линейной алгебры. Я всегда пишу вспомогательную функцию для проверки ответов и время от времени запускаю ее.

• Волосатый код структуры данных с перекрестными ссылками, указателями, обратными указателями и методами для постепенного поддержания его согласованности. Их действительно легко взломать, поэтому модульные тесты помогают увидеть, не работают ли они.

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

Тип тестирования, который мне нужен больше, чем модульное тестирование, - это тестирование покрытия. Испробовал ли я все возможные функции и комбинации функций? Поскольку это очень большое пространство и писать автоматические тесты для его покрытия невозможно, я часто провожу тестирование в режиме Монте-Карло, когда выбор функций выбирается случайным образом и передается в систему. Затем результат проверяется автоматически и / или вручную.

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

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

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

У меня также есть огромный кусок кода, не подлежащего модульному тестированию, с соответствующими интеграционными тестами.