Еще один вопрос модульного тестирования / покрытия кода. Мой подход вменяемый? - PullRequest
Новая
       14

Еще один вопрос модульного тестирования / покрытия кода. Мой подход вменяемый?

1 голос
/ 27 октября 2009

Это еще один вопрос модульного тестирования. Я пытаюсь извлечь знания из ряда мест о том, как действовать, и я хотел отразить свое текущее понимание из коллекции экспертов здесь.

предположим, что проект, для которого все зависимости, кроме функций opengl, статически связаны (кроме времени выполнения c)

Мое текущее понимание:

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

  2. Инструмент покрытия кода, такой как CoverageMeter, установлен в основном проекте и имеет собственную конфигурацию сборки, такую ​​как test вместо debug. Это поместит метрики в объектный код для внешнего инструмента «просмотра» для получения метрик.

  3. В то же время основное приложение создается как библиотека в конфигурации Test, поэтому внешний тестовый модуль Project использует объектный код для запуска своих тестов. В то же время, код CoverageMeter включен в библиотеку, которую использует для тестирования проект модульного теста, что позволяет метрикам покрытия измерять, сколько кода выполняется в модульных тестах.

  4. С конфигурацией тестирования, сделанной отдельно от выпуска или отладки, библиотеки заполнителей могут использоваться для разрыва зависимостей, таких как opengl.

Мои вопросы действительно следующие: Этот пирог в небе? Правильно ли я понимаю? могу ли я на самом деле сделать первое предложение 3, это то, как я могу получить код модульного теста для запуска сборки объектного кода в основном проекте приложения, или есть другой способ?

Я ненормальный? Я открыт для любой критики. Заранее спасибо за ваше время.

ОБНОВЛЕНИЕ: Похоже, у меня есть правильное представление о том, что нужно делать в моих модульных тестах, но меня беспокоит вопрос 3. Правильно ли я понимаю эти компоненты?

Спасибо за ваши ответы. Это хорошо, чтобы получить обратную связь! Это будет мой первый большой проект, и я пытаюсь понять все вовлеченные части. Я ценю указатели!

Josh

1 Ответ

0 голосов
/ 27 октября 2009

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

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

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

...