Где я могу разместить источник модульного тестирования и раскрыть внутренние компоненты? - PullRequest
Новая
       24

Где я могу разместить источник модульного тестирования и раскрыть внутренние компоненты?

3 голосов
/ 12 сентября 2011

Я принимаю проект, который предоставляет компоненты через ATL.

Я вижу две основные области для модульного теста, охватываемые этой настройкой:

  • Тестирование внутренних компонентов (может или не может быть выставлено через COM)
  • Тестирование внешних открытых компонентов (или тестирование открытого интерфейса)

В настоящее время в рамках проекта все модульные тесты внутренних компонентов находятся внутри решения.Они активируются с помощью флага препроцессора, который компилирует его и запускает при запуске.

Из проведенного мною исследования выясняется, что «нормой» является размещение модульного тестирования в другом подпроекте и наличие хуков подачи основного решения для модульных тестов для доступа к внутренним компонентам.При такой настройке решение для модульного тестирования устанавливает зависимость от тестируемого решения.Является ли это действительно «нормой», или есть много людей, которые размещают свои модули модульного тестирования в тестируемом решении (иначе говоря, модульный тест не подпроект, а скорее свободные cppsкоторые #ifdef вышли бы, если флаг препроцессора не указан)?

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

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

Итак, мои вопросы таковы:

  1. Является ли нормой помещение модульных тестов в отдельный (под) проект и предоставление компонентов из источника, который будет тестироваться (либо через ловушки,предоставление определения класса и т. д.)?
  2. Каков наилучший способ предоставления внутренних компонентов из библиотеки DLL COM?
  3. Будет ли флаг препроцессора, который разрешает __declspec для внутренних компонентов бытьпроверил плохую идею?Кто-нибудь еще делал это с помощью своих модульных тестов, где тестируемый элемент обычно не экспонируется во время нормальной работы?

Спасибо за комментарии!

Ответы [ 3 ]

4 голосов
/ 13 сентября 2011

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

Таким образом, решение будет выглядеть следующим образом:

MainSolution

  • ProjCommonLib
  • ProjExportsLib
  • ProjImportsLib
  • ProjOtherStuffLib
  • COMDLL-Proj
  • UnitTestsFolder
    • ProjCommonLibTests
    • ProjExportsLibTests
    • ProjOtherStuffLibTests
    • COMDLL-ProjTests

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

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

1 голос
/ 13 сентября 2011

Я бы сказал, что у вас есть свободный выбор: встраивать тесты в существующие проекты или создавать новый. Я выбираю первый подход с моими тестами cppunit, поскольку это означает, что вам не нужно создавать новые проекты, но с проектами C # я использую среду модульного тестирования Visual Studio, которая выполняет основную работу по созданию и поддержке отдельного проекта.

У меня никогда не было проблем с тем, чтобы мои #ifdef 'ed блоки не перекомпилировались - проверка зависимостей проследит за этим (если вы выставили их в отдельную dll, а затем использовали экспорт, то это было бы проблемой.

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

Одна вещь, которая мне нравится в cppunit, которую (насколько я смог найти) не поддерживается в gtest, это то, что первый сбой в устройстве приводит к отказу устройства, поэтому вы можете сделать это: 

CPPUNIT_ASSERT(pointer!=NULL);
CPPUNIT_ASSERT(pointer->deferenceIt());  // if the pointer was null it would have returned above

gtest продолжит работу в этом случае и завершится сбоем во второй строке. Если тесты cppunit основаны на этом поведении, то это еще больше затруднит перенос.

0 голосов
/ 12 сентября 2011

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

...