Как вы проводите модульные тесты? Флаги компилятора? Статические библиотеки?

Question

Я только начинаю с TDD, и мне любопытно, что подходы других предпринимают для проведения своих тестов. Для справки, я использую платформу тестирования Google, но я считаю, что этот вопрос применим к большинству других систем тестирования и к языкам, отличным от C/C++.

Мой общий подход до сих пор был сделать один из трех вещей:

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

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

3. Внедрите тестовый код непосредственно в приложение и, учитывая, что некоторые ключи командной строки запускают само приложение или запускают тесты, встроенные в приложение.

Ни одно из этих решений не особенно элегантный ...

Как вы это сделать?

Answer 1

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

Для кода, который строится в exe, у меня либо есть отдельный тестовый проект, который просто включает исходные файлы, которые находятся под тестированием, и которые обычно встроены в exe. Или я создаю новую старую lib, которая содержит большую часть exe и проверьте, что так же, как я тестирую все мои другие статические библиотеки. Я обнаружил, что обычно я использую подход «самый код в библиотеке» с новыми проектами и «вытаскиваю исходные файлы из проекта exe в проект тестового проекта, когда я выполняю ретро-тесты для существующих приложений.

Мне не нравятся ваши варианты 2 и 3 вообще. Управление конфигурациями сборки для 2, вероятно, сложнее, чем наличие отдельного тестового проекта, который просто тянет в нужные ему источники и включает все тесты в exe, как вы предлагаете в 3, просто неправильно;)

Answer 2

Я использую сторонних тестировщиков со своей структурой и включая тестирование в скрипте сборки. Тесты находятся вне производственного кода (внешняя dll).

Answer 3

Ваш подход №. 1 - это то, как я всегда делал это на C/C++ и Java. Большая часть кода приложения находится в статической библиотеке, и я стараюсь свести к минимуму количество дополнительного кода, необходимого для приложения.

Способ, которым я подхожу к TDD в Python и других динамических языках, немного отличается тем, что я оставляю исходный код приложения и тесты, лежащие вокруг, и тестовый бегун находит тесты и запускает их.

Answer 4

Я использую два подхода, для dlls Я просто связываю свои модульные тесты с dll, легко. Для исполняемых файлов я включаю исходные файлы, которые тестируются как в исполняемом проекте, так и в проекте тестирования модулей. Это немного добавляет время сборки, но означает, что мне не нужно отделять исполняемый файл от статической библиотеки lib и основной функции.

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

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

Answer 5

Для приложений на C/C++ я стараюсь иметь как можно больше кода в одной или нескольких DLL, причем основное приложение является минимальным для запуска и передачи в DLL. Dll намного проще тестировать, поскольку они могут экспортировать столько точек входа, сколько мне нравится в тестовом приложении.

Я использую отдельное тестовое приложение, которое ссылается на Dll (ы).Я категорически настаиваю на сохранении кода проверки и кода продукта в отдельных модулях.

Answer 6

Я иду с № 1, некоторые причины

• Это позволяет проверить, что каждый Lib ссылки правильно
• Вы не хотите дополнительный код в продукте
• легче отлаживать отдельных мелких тестовые программы
• Вам может понадобиться несколько исполняемых файлов для некоторых тестов (например, тесты связи)

Для C++ строить и тестировать, я как использовать CMake, который может выполнять выбор целевых исполняемых файлов в качестве тестов и распечатывать сводку результатов.

Answer 7

Лично я использую другой подход, который немного зависит от ваших:

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

Затем вы можете создать тестовый проект, связанный с базой тестов и ранее созданной статической библиотекой.

Вот некоторые темы, соответствующие вашему вопросу:

• Visual Studio C++: Unit test exe project with google test?
• Linker error - linking two "application" type projects in order to use Google Test