C # - исключая юнит-тесты из релизной версии вашего проекта - PullRequest
Новая
       27

C # - исключая юнит-тесты из релизной версии вашего проекта

22 голосов
/ 17 сентября 2008

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

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

Одно решение, которое я нашел, - заключить все ваши модульные тесты в директивы #if DEBUG - #endif: когда ни один код не ссылается на сборку модульного тестирования, компилятор достаточно умен, чтобы опустить ссылку в скомпилированном коде.

Существуют ли другие (возможно, более удобные) варианты для достижения аналогичной цели?

Ответы [ 13 ]

42 голосов
/ 17 сентября 2008

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

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

20 голосов
/ 17 сентября 2008

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

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

[assembly: InternalsVisibleTo("UnitTestProjectName")]
10 голосов
/ 17 сентября 2008

.NET Framework после v2 имеет полезную функцию, позволяющую пометить сборку атрибутом InternalsVisibleTo, который позволяет сборке получить доступ к другой.
Этакая функция сборки туннеля.

7 голосов
/ 23 сентября 2008

Еще одной альтернативой использованию директив компилятора в файле или созданием отдельного проекта является просто создание дополнительных файлов .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>
3 голосов
/ 17 сентября 2008

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

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

2 голосов
/ 17 сентября 2008

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

2 голосов
/ 17 сентября 2008

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

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

2 голосов
/ 17 сентября 2008

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

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

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

1 голос
/ 13 апреля 2009

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

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

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

1 голос
/ 17 сентября 2008

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

Страница:
...