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

Question

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

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

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

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

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

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

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

Answer 1

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

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

Answer 2

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

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

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

Answer 3

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

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

Answer 4

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

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

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

Answer 5

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

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

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

Answer 6

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

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

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

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

• Visual Studio C ++: модульный тестовый exe-проект с google test?
• Ошибка компоновщика - связывание двух проектов типа «приложение» для использования Google Test

Answer 7

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