Эффективная работа с модульными тестами / Кто-нибудь пробовал подход в сборке?

Question

Я пытаюсь возобновить юнит-тестирование в моей команде, так как наше текущее покрытие очень плохое.

Наша система довольно большая 40+ проектов / сборок. В настоящее время мы используем проект с именем [SystemName] .Test.csproj, где весь тестовый код выгружен и организован для представления пространств имен с использованием папок. Этот подход не очень масштабируемый и затрудняет поиск тестов.

Я думал о том, чтобы добавить папку «Тесты» в каждый проект, это поместило бы юнит-тесты «в лицо разработчикам» и облегчило бы их поиск. Недостатком является то, что производственный код выпуска будет содержать ссылки на nunit, nmocks, а также тестовый код и тестовые данные ... Кто-нибудь пробовал этот подход?

Как все остальные работают с юнит-тестами в больших проектах? Наличие проекта Tests для «реального» проекта / сборки может привести к появлению слишком большого количества новых проектов.

Заранее спасибо

Answer 1

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

Вы не говорите, почему тесты трудно найти. Если они отражают структуру того, что они тестируют, то найти их не сложнее, чем код, который они тестируют.

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

Мы склонны идти на тесты в их собственном проекте, но этот проект находится в подпапке Tests (или Tests.Integration или чего бы то ни было для тестов) сборки, которую они тестируют. Таким образом, тесты получаются, когда код для проекта извлекается, и у вас нет папок с тестовыми проектами, загрязняющих структуру каталогов на уровне проекта. Но в итоге у вас есть как минимум 1 тестовый проект для каждой сборки. Я думаю, что это нормально, если у вас не много небольших сборок, но в этом случае вам действительно нужно иметь код для всех них в идеале все время, или вы могли бы просто иметь код для сборок, над которыми вы работаете локально, а другие сборки просто ссылаются на dll?

Answer 2

Я работал над большим проектом (5 миллионов строк кода, ~ 160 000 модульных тестов), в котором тестовый класс помещался внизу каждого файла, в отдельном пространстве имен, обернутом в #if DEBUG.

Ссылки на NUnit существовали в производственном процессе, но тестовый код не был включен в сборку выпуска, поэтому он не увеличил производственные DLL.

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

Это работало довольно успешно для проекта, но мнения и пробег могут меняться в наши дни :) Структура, в которой я сейчас работаю, имеет структуру, очень похожую на ту, которую описывает Сэм Холдер.

Answer 3

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