Как вы настраиваете свои модульные тестовые проекты в .Net?

Question

Можете ли вы поделиться тем, как вы настраиваете свои проекты модульного тестирования в своих решениях .net?

Я могу представить несколько возможных методологий. Например:

1. Наличие отдельного решения для модульных тестов, идеальное отражение структуры исходного тестируемого решения кода.

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

3. Иметь проект модульного тестирования для каждого проекта кода и располагаться рядом с ним внутри древовидной структуры решения.

4. Имейте проект модульного тестирования, охватывающий несколько проектов кода, расположенных рядом с ними в древовидной структуре.

Хотелось бы услышать, как вы на самом деле делаете это в своих решениях.

Answer 1

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

Есть несколько разных способов сделать это.

• Один тестовый проект для одного решения (Product.UnitTests.csproj)
• Один тестовый проект для системы (Product.SystemName.UnitTests.csproj)
• Сопоставление производственных и тестовых проектов один к одному (Product.ProjectName.csproj и Product.ProjectName.Tests.csproj)

У каждого есть свои компромиссы, которые вы должны взвесить.

Один тестовый проект для одного решения

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

Это означает, что процесс сборки сокращается (когда у вас есть решения с множеством проектов, уменьшение количества сборок также сокращает время сборки) и нет необходимости поддерживать файлы .nunit или тому подобное.

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

Один тестовый проект для системы

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

Индивидуальное сопоставление производственных проектов и тестовых проектов

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

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

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

Answer 2

Определенно одно решение, но отдельные проекты:

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

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

Answer 3

Следующая структура хорошо сработала для меня. Он также позволяет разделить производственный и тестовый код.

\source
\source\code\MainSolution.sln
\source\code\Project1
\source\code\...
\source\test\TestSolution.sln
\source\test\TestProject1
\source\test\...

Answer 4

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

Answer 5

Имеют одно и то же решение для обоих, но 2 проекта, проект .NET и проект NUnit (один к одному), теперь, если у меня есть решение с несколькими проектами, у меня есть только один проект NUnit для решения, как это и 1 для каждого проекта. Я думаю, что это хороший способ, потому что он помогает мне организовывать мои проекты.

Кроме того, вы можете взглянуть на эту книгу: http://www.artofunittesting.com/ это очень хорошо.