Вы помещаете модульные тесты в тот же проект или другой проект?

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

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

При необходимости в доступе к внутренним членам производственного кода используйте InternalsVisibleTo.

Я не понимаю частого возражения на развертывание тестов с производственным кодом. Я вел, команда в небольшом микроограничении (вырос с 14 до 130 человек). У нас была приблизительно полдюжина приложений Java, и мы нашли это ЧРЕЗВЫЧАЙНО valueable для развертывания тестов в поле для выполнения их на определенной машине, которая показывала необычное поведение. Случайные проблемы происходят в поле, и способность бросить несколько тысяч модульных тестов в тайну с нулевой стоимостью была неоценимыми и часто диагностируемыми проблемами в минутах... включая проблемы установки, облупленные проблемы RAM, определенные для машины проблемы, облупленные сетевые проблемы, и т.д., и т.д. Я думаю, что невероятно ценно поместить тесты в поле. Кроме того, случайные проблемы открываются наугад времена, и хорошо иметь модульные тесты, находящиеся там уже ожидающий, чтобы быть выполненным в уведомлении моментов. Пространство на жестком диске является дешевым. Точно так же, как мы пытаемся держать вместе данные и функции (дизайн OO), я думаю, что существует что-то существенно ценное в держании вместе кода и тестов (функция + тесты, которые проверяют функции).

Я хотел бы поместить свои тесты в тот же проект в C#/.NET/Visual Studio 2008, но я все еще не исследовал это достаточно для достижения его.

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

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

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

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

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

Я поместил их в отдельные проекты. Название зеркал блока название пространств имен, как правило для нас. Таким образом, если существует проект под названием Компания. Продукт. Feature.sln, это имеет вывод (имя сборки) Company.Product.Feature.dll. Тестовым проектом является Компания. Продукт. Функция. Tests.sln, приводя к Company.Product.Feature.Tests.dll.

Вы лучше всего сохраняете их в едином решении и управляете выводом через Менеджер конфигурации. У нас есть именованная конфигурация для каждого из основных ответвлений (Разработка, Интеграция, Производство) вместо использования Отладки по умолчанию и Выпуска. После того как у Вас есть своя установка конфигураций, можно затем включать или исключить их путем нажатия на флажок "Build" в Менеджере конфигурации. (Для получения Менеджера конфигурации щелкните правой кнопкой по решению и перейдите к Менеджеру конфигурации.) Примечание, что я нахожу, что CM в Visual Studio время от времени багги. Пару раз я должен был войти в проект и/или файлы решения для чистки целей, которые он создал.

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

Кроме того, мы раньше делали, XCopy понижается машины сборки. Сценарий просто опустил бы копировать что-либо названное *.Tests.Dll от того, чтобы быть развернутым. Это было просто, но работало.

Отдельные проекты, хотя я дебатирую со мной, должны ли они совместно использовать тот же svn. В данный момент я даю им отдельные репозитории SVN, один названный

"MyProject" - для самого проекта

и один названный

"MyProjectTests" - для тестов, связанных с MyProject.

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

Но я все больше склонен иметь что-то как следующее, в единственном репозитории SVN, для каждого проекта.

MyProject
|\Trunk
| |\Code
|  \Tests
|\Tags
| |\0.1
| | |\Code
| |  \Tests
|  \0.2
|   |\Code
|    \Tests
\Branches
  \MyFork
   |\Code
    \Test

Мне было бы интересно знать то, что другие люди думают об этом решении.

Как другие ответили - помещенные тесты в отдельных проектах

Одна вещь, которая не была упомянута, то, что Вы не можете на самом деле работать nunit3-console.exe против ничего кроме .dll файлы.

, Если Вы - планирование запущения Ваших тестов через TeamCity, это создаст проблему.

Скажем, у Вас есть проект консольного приложения. Когда Вы компилируете, это возвращает исполняемый файл .exe bin папка.

От nunit3-console.exe Вы не смогли бы запустить любые тесты, определенные в том консольном приложении.

, Другими словами, консольное приложение возвращается exe, файл и библиотека классов возвращаются dll файлы.

я просто получил бит этим сегодня, и он сосет :(