Организация проектов модульных испытаний .NET

Что бы вы сказали, это лучший способ управлять модульными тестами в большом приложении .net? Лучше ли добавлять тестовый проект для каждого отдельного проекта в решении или один крупный проект испытаний для всех тестов в остальных проектах?

Например, если в решении есть 10 проектов, лучше ли иметь 10 дополнительных тестовых проектов или один большой проект тестов для всего решения?

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

Просьба указать преимущества/недостатки для каждого выбора в ваших ответах.

Ответ 1

Фил Хаак написал хорошую статью о структурировании модульных тестов. Это стало моей личной практикой при написании модульных тестов. Вот ссылка на его статью http://haacked.com/archive/2012/01/02/structuring-unit-tests.aspx

Что касается вашего вопроса, я бы всегда создавал отдельный проект для unit test и назовет его с помощью .UnitTests(я делаю это, чтобы различать тесты единиц и интеграции). Например, если моим основным проектом является Sample.WebUI, тест будет Sample.WebUI.UnitTests.

Верно, что модульные тесты добавляют дополнительное время для компиляции, но я считаю, что это небольшая проблема. Я работаю над решением с 17 проектами (за исключением модульных тестов), и требуется всего 50-60 секунд, чтобы скомпилировать все. Это достаточно времени, чтобы оторвать глаз от монитора и посмотреть на что-то другое для изменения: -)

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

Ответ 2

Лично я предпочитаю иметь выделенный тестовый проект для реального проекта. Когда дело доходит до создания новой функции/модуля/проекта, мне гораздо лучше иметь возможность быстро отфильтровывать набор других нерелевантных тестовых проектов. Это делает цикл TDD намного быстрее, чтобы иметь возможность быстро запускать тесты для моего нового проекта по мере его разработки.

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

Ответ 3

Посмотрите на этот вопрос: "Лучшая практика: Организуйте тесты единиц"

хотя размер решения, о котором идет речь, отличается, рекомендации, написанные там, все еще действительны.

Ответ 4

Мой личный выбор - иметь один тестовый проект для каждого проекта с помощью только модульных тестов. Структура папок этого тестового проекта точно такая же, как и тестируемый проект. Кроме того, при необходимости они делают так много проектов интеграции-тестирования.

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

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