C # - исключение модульных тестов из релизной версии вашего проекта.

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

Да, как говорит Гэри, это также заставляет вас проверять поведение общедоступными методами, а не играть с внутренностями ваши классы

Как отмечают другие, отдельный тестовый проект (для каждого нормального проекта) - хороший способ сделать это. Я обычно зеркалирую пространства имен и создаю тестовый класс для каждого нормального класса с добавлением «test» к имени. Это поддерживается непосредственно в IDE, если у вас есть Visual Studio Team System, которая может автоматически создавать тестовые классы и методы в другом проекте.

Одна вещь, которую следует запомнить, если вы хотите протестировать классы и методы с «внутренним» аксессором, - это добавить следующую строку в файл AssemblyInfo.cs для каждого проекта, который нужно протестировать:

[assembly: InternalsVisibleTo("UnitTestProjectName")]

В .Net framework после v2 есть полезная функция, в которой вы можете пометить сборку атрибутом InternalsVisibleTo, который позволяет другой сборке получить доступ к ней.
Что-то вроде функции туннелирования сборок.

Еще одна альтернатива использованию директив компилятора в файле или созданию отдельного проекта - это просто создание дополнительных файлов .cs в вашем проекте.

С помощью магии в самом файле проекта вы можете продиктовать это:

1. Библиотеки DLL nunit.framework упоминаются только в отладочной сборке, и
2. ваши тестовые файлы включены только в отладочные сборки

Пример отрывка из .csproj:

<Project DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003" ToolsVersion="3.5">

   ...

   <Reference Include="nunit.framework" Condition=" '$(Configuration)'=='Debug' ">
      <SpecificVersion>False</SpecificVersion>
      <HintPath>..\..\debug\nunit.framework.dll</HintPath>
   </Reference>

   ...

   <Compile Include="Test\ClassTest.cs" Condition=" '$(Configuration)'=='Debug' " />

   ...
</Project>

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

Поддержание параллельных пространств имен и использование разумного соглашения об именах для тестов (например, MyClass и MyClassTest) поможет вам сохранить кодовую базу поддерживаемой.

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

Сложность, конечно, возникает, когда у бизнеса в решении 55 проектов и 60% из них тестовые. Считай, что тебе повезло.

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

Для каждого проекта существует соответствующий тестовый проект, содержащий тесты.

Например. для сборки с именем, скажем, «Acme.BillingSystem.Utils», будет тестовая сборка с именем «Acme.BillingSystem.Utils.Test».

Исключите ее из поставляемой версии продукта, не отправляя эту dll.

Еще предстоит принять во внимание одну вещь: в версиях VisualStudio до 2005 года нельзя было ссылаться на проекты сборки EXE из других проектов. Итак, если вы работаете над унаследованным проектом в VS.NET, ваши варианты будут следующими:

• Поместите модульные тесты в один и тот же проект и используйте условную компиляцию, чтобы исключить их из сборок выпуска.
• Переместите все в сборки dll, чтобы ваш exe был просто точкой входа.
• Обойти IDE, взломав файл проекта в текстовом редакторе.

Из трех условная компиляция наименее подвержена ошибкам.

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

Если тег #if (DEBUG) допускает чистую «релизную» версию, зачем вам нужен отдельный проект для тестов. Пример nunit LibarryA / B (да, я знаю его пример) делает это. В настоящее время борюсь со сценарием. Использовал отдельный проект, но, похоже, это, возможно, позволит улучшить производительность. По-прежнему хуммин и хавин.

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

#if TEST
#endif

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

Я всегда создаю отдельный проект Acme.Stuff.Test, который компилируется отдельно.

Обратный аргумент: зачем вам сдавать тесты? Почему бы не сдать тест? Если вы доставляете тесты вместе с исполнителем тестов, у вас есть некоторый уровень приемочного тестирования и самотестирования, поставляемых вместе с продуктом.

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