Проекты NUnit vs Visual Studio 2008 для модульного тестирования?

Я собираюсь начать новый проект на работе и хочу пройти модульное тестирование. Мы будем использовать VS 2008, С# и материал ASP.NET MVC. Я рассматриваю использование NUnit или встроенных тестовых проектов, которые VS2008 имеет, но я открыт для исследования других предложений. Является ли одна система лучше, чем другая, или, возможно, проще в использовании/понимании, чем в другой? Я ищу, чтобы этот проект был создан как "лучшая практика" для наших усилий в области развития в будущем.

Спасибо за любую помощь и предложения!

Ответ 1

Daok назвал все про тестируемые проекты VS2008, вот про NUnit.

NUnit имеет насмешливую структуру.
NUnit можно запустить за пределами IDE, это может быть полезно, если вы хотите для запуска тестов на сервере сборки без MS как CC.Net
NUnit выпускает больше версий чем визуальная студия. У вас нет подождать годы для новой версии И вам не нужно устанавливать новую версию IDE для получить новые функции.
Разрабатываются расширения для NUnit, например, для строк-тестов и т.д.
Тесты Visual Studio занимают много времени чтобы начать по какой-то причине. Это лучше в 2008 году, но все еще слишком медленно для моего вкуса. Быстрое выполнение теста посмотреть, не сломали ли вы что-то может занять слишком много времени. NUnit с что-то вроде Testdriven.Net для запуска тесты из IDE на самом деле Быстрее. особенно при работе одиночные тесты.
В дополнение к Kjetil Klaussen это вызвано тестировщиком Visual Studio, запуск тестов MSTest в TestDriven.Net делает производительность MSTest сравнимой с NUnit.

Ответ 2

Структура модульного тестирования на самом деле не имеет большого значения, поскольку вы можете конвертировать тестовые классы с отдельными файлами проекта и условной компиляцией (например, VS- > NUnit):

 #if !NUNIT
  using Microsoft.VisualStudio.TestTools.UnitTesting;
 #else
  using NUnit.Framework;
  using TestClass = NUnit.Framework.TestFixtureAttribute;
  using TestMethod = NUnit.Framework.TestAttribute;
  using TestInitialize = NUnit.Framework.SetUpAttribute;
  using TestCleanup = NUnit.Framework.TearDownAttribute;
  using TestContext = System.String;
  using DeploymentItem = NUnit.Framework.DescriptionAttribute;
 #endif

Плагин TestDriven.Net хорош и не очень дорог... С простым VS2008 вам нужно найти тест из вашего тестового класса или тестового списка. С помощью TestDriven.Net вы можете запустить свой тест непосредственно из класса, который вы тестируете. В конце концов, unit test должен быть прост в обслуживании и рядом с разработчиком.

Ответ 3

Преимущества/изменения VS2008 Встроенная модульная система тестирования

Версия 2008 теперь доступна в профессиональные издания (до него требуемые дорогие версии VS, это только для блока разработчика тестирование.), которые оставили много разработчиков с единственным выбором открытые/внешние схемы тестирования.
Встроенный API, поддерживаемый отдельной компанией.
Используйте те же инструменты для запуска и создания тестов (вы можете запускать их с помощью командной строки также MSTest)
Простой дизайн (без рамки Mock, но это отличная отправная точка для многих программистов).
Долгосрочная поддержка (я все еще помню, что случилось с nDoc, я не хочу привязываться к платформе тестирования, которая может не поддерживаться через 5 лет, но я все еще считаю nUnit отличной структурой.)
Если вы используете сервер фундаментов команды в качестве своего бэкэнд, вы можете легко создать рабочие элементы или ошибки с неудавшимися тестовыми данными.

Ответ 4

Я использую NUnit в течение 2 лет. Все в порядке, но я должен сказать, что система Unit в VS довольно хороша, потому что она находится внутри Gui и может более легко выполнять тест для частных функций без необходимости возиться. Кроме того, Unit Testing VS позволяет вам делать покрытие и другие вещи, которые NUnit самостоятельно не может сделать.

Ответ 5

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

Кроме того, если вам не хватает плагина, такого как TestDriven.NET, вы не можете отлаживать модульные тесты NUnit (или MbUnit, xUnit и т.д.) в среде Visual Studio, как вы можете это сделать с помощью оболочки тестирования Microsoft VS, которая встроенный.

Ответ 6

Немного не по теме, но если вы поедете с NUnit, я могу порекомендовать использовать ReSharper - он добавляет некоторые кнопки в VS UI, что сделать намного легче запускать и отлаживать тесты из среды IDE.

Этот обзор немного устарел, но объясняет это более подробно:

http://codebetter.com/blogs/paul.laudeman/archive/2006/08/15/Using-ReSharper-as-an-essential-part-of-your-TDD-toolkit.aspx

Ответ 7

XUnit - еще одна возможность для нового проекта. Возможно, это был более интуитивный синтаксис, но на самом деле он не совместим с другими средами.

http://www.codeplex.com/xunit

Ответ 8

Моя основная говядина с VS-модульными испытаниями над NUnit - это создание VS-теста, которое позволяет вводить кучу сгенерированного кода для доступа к частному члену.

Некоторые могут захотеть проверить свои частные методы, а некоторые - нет.

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

Ответ 9

Я сделал TDD, используя оба и (возможно, я немного тупой). nUnit кажется намного быстрее и проще использовать для меня. И когда я говорю много, я имею в виду много.

В MS Test слишком много атрибутов, везде - код, который выполняет реальные тесты, - это крошечные строки, которые вы можете прочитать здесь и там. Большой беспорядок. В nUnit код, выполняющий тест, просто доминирует над атрибутами, как и должно быть.

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

В VSTS список тестов застрял в нижней части экрана, он маленький и уродливый. Вы должны посмотреть дважды, чтобы узнать, что произошло. И вы не можете запустить только один тест (ну, я еще не выяснил!).

Но я, возможно, ошибаюсь, конечно, я просто прочитал около 21 сообщения в блоге о том, как сделать простой TDD с помощью VSTS. Я должен был прочитать больше, вы правы.

Для nUnit я прочитал один. И я был TDDing в тот же день. С удовольствием.

Кстати, я обычно люблю продукты Microsoft. Visual Studio - действительно лучший инструмент, который разработчик может купить - но управление TDD и Work Item в Visual Studio Team System действительно отстойно.

Все самое лучшее. Sylvain.

Ответ 10

Сначала я хочу исправить неправильный оператор: вы можете запустить msTest за пределами визуальной студии с помощью командной строки. Хотя некоторые инструменты CI, такие как TeamCity, имеют лучшую поддержку NUnit (возможно, это изменится, поскольку msTest станет более популярным). В моем текущем проекте мы используем оба варианта, и мы обнаружили, что mstest всегда работает как 32-разрядный, а NUnit работает либо как 32-битный, либо 64-битный тест, который имеет значение только в том случае, если ваш код использует собственный код, зависящий от 32/64.

Ответ 11

Я получил сообщения о том, что "файловая структура NUnit богаче VSTest"... Конечно, если вы предпочитаете структуру файлов NUnit, вы можете использовать это решение по-другому, например (NUnit- > VS):

 #if !MSTEST
  using NUnit.Framework;
 #else
  using Microsoft.VisualStudio.TestTools.UnitTesting;
  using TestFixture = Microsoft.VisualStudio.TestTools.UnitTesting.TestClassAttribute;
  using Test = Microsoft.VisualStudio.TestTools.UnitTesting.TestMethodAttribute;
  using SetUp = Microsoft.VisualStudio.TestTools.UnitTesting.TestInitializeAttribute;
  using TearDown = Microsoft.VisualStudio.TestTools.UnitTesting.TestCleanupAttribute;
 #endif

Или любое другое преобразование...:-) Это использование здесь просто псевдонима для компилятора.

Ответ 12

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

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

NUnit действительно делает то, что мне нужно. Единственное, чего не хватает в NUnit, это Visual Studio Addin, который может отображать состояние Red/Green (как VSTS) каждого теста.

Ответ 13

Ответ 14

Если вы рассматриваете MSTest или nUnit, я рекомендую вам посмотреть mbUnit. Мои причины

Совместимость с TestDriven.Net. Ничто не сравнится с TestDriven.Net.ReRunWithDebugger, связанным с комбинацией клавиш.
Рамка Галлио. Gallio - испытательный бегун, как nUnits. Единственное различие заключается в том, что вам не нужно писать свои тесты в nUnit, msTest, xUnit или mbUnit. Они все запущены.
Совместимость с nUnit. Все функции nUnit поддерживаются mbUnit. Я думаю, вам даже не нужно менять свои атрибуты (нужно будет это проверить), просто ваша ссылка и использование.
Утверждается коллекция. mbUnit имеет больше случаев Assert, включая класс CollectionAssert. В основном вам больше не нужно писать собственные тесты, чтобы увидеть, совпадают ли 2 коллекции.
Комбинаторные тесты. Было бы здорово, если бы вы могли предоставить два набора данных и получить тест для всех комбинаций данных. Он находится в mbUnit.

Я изначально взял mbUnit из-за его функциональности [RowTest....], и я не нашел единственной причины вернуться. Я переместил все свои активные тестовые сюиты из nUnit и никогда не оглядывался назад. С тех пор я превратил две разные группы разработчиков в преимущества.

Ответ 15

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

NUnit
MbUnit
MSTest
XUnit

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

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

Ответ 16

Мне не нравится встроенная среда тестирования VS, потому что это заставляет вас создавать отдельный проект, а не тестировать его как часть тестируемого проекта.

Ответ 17

MSTest - это, по сути, NUnit, немного переработанный, с несколькими новыми функциями (такими как сборка и отрыв, а не только крепление и уровень теста) и отсутствие некоторых из лучших битов (например, синтаксис синтаксиса нового 2.4). NUnit более зрелый, и его больше поддерживают другие производители; и, конечно же, поскольку он всегда был бесплатным (в то время как MSTest только попал в профессиональную версию 2008 года, до этого он стал более дорогим SKU), большинство проектов ALT.NET используют его.

Сказав это, есть некоторые компании, которые невероятно неохотно используют что-то, у которого на нем нет ярлыка Microsoft, и особенно для этого кода OSS. Таким образом, наличие официальной тестовой среды MS может быть мотивом того, что эти компании должны пройти тестирование; и, честно говоря, это испытание, которое имеет значение, а не тот инструмент, который вы используете (и используя код Tuomas Hietanen выше, вы можете сделать свою тестовую среду взаимозаменяемой).

Ответ 18

С выпуском в .NET 4.0 системы Код Контракты и доступности static checker, вам необходимо теоретически написать меньше тестовых примеров, а инструмент, например Pex, поможет определить те случаев. Относясь к обсуждению, если вам нужно делать меньше с вашими модульными тестами, потому что ваши контракты покрывают ваш хвост, то почему бы просто не пойти дальше и не использовать встроенные части, поскольку это одна меньшая зависимость для управления. В эти дни я все о простоте.: -)

См. также:

Ответ 19

Я бы предпочел использовать MS little test framework, но теперь я придерживаюсь NUnit. Проблемы с MS обычно (для меня)

Общий файл "тестов" (бессмысленный), который должен поддерживаться
Списки тестов вызывают конфликты с несколькими разработчиками /VCS
Плохой интегрированный пользовательский интерфейс - запутанная настройка, обременительный выбор тестов
Нет хорошего внешнего бегуна

Предостережение - Если бы я тестировал сайт aspx, я бы определенно использовал MS - Если бы я развивал соло, то и MS было бы хорошо - Если у меня было ограниченное умение и не удалось настроить NUnit:)

Мне гораздо проще просто написать мои тесты и запустить NUnitGUI или один из других интерфейсов (testDriven далеко далеко далеко переоценен). Настройка отладки с версией командной строки также довольно проста.