Как эффективный способ организовать проекты C ++, которые будут подвергнуты модульному тестированию?

Question

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

Вот несколько способов, которые я собрал:

Метод A

• Проект A : проект приложения (.exe), который «включает» классы из проекта C
• Проект B : модульный тест (.exe)проект, который "включает" классы из проекта C
• проект C : проект статической библиотеки (.lib), в котором хранятся все классы, которые использует проект A

Метод B

• Проект A : проект приложения (.exe) со всеми классами внутри себя.
• Проект B : Проект модульного теста (.exe), который «связывает» классы в проекте A

Метод C (от Мигеля)

• только одинпроект с тремя конфигурациями:
  • Отладка: сборка приложения .exe в режиме отладки.
  • Выпуск: сборка приложения .exe в режиме выпуска.
  • Тест: сборкакаркас модульного тестирования, заменяет main () вашего приложения на main () модульного тестирования * (1048 *

) Что является более подходящим способом?У вас есть другие предложения?

Answer 1

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

Основными преимуществами такого подхода являются:

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

Answer 2

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

Я хотел бы предложить следующее как лучший вариант, чем ваши методы A и B:

МЕТОД C

• только один проект с тремя конфигурациями:
  • Отладка: сборка приложения .exe в режиме отладки.
  • Release: сборка приложения .exe в режиме выпуска.
  • Test: создает структуру модульного тестирования, заменяет main () вашего приложения на main () модульного тестирования

Если вы считаете, что вам нужно, вы можете разделить цель Test на Debug и Release.

Answer 3

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