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

Question

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

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

Answer 1

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

Answer 2

.NET Testing Framework Advice и .NET Unit Testing packages?.

Answer 3

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

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

Answer 4

Каркас модульного тестирования на самом деле не имеет большого значения, потому что вы можете преобразовать классы теста с отдельными файлами проекта и условной компиляции (как это, 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 

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

Answer 5

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

http://www.codeplex.com/xunit

Answer 6

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

Answer 7

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

• NUnit
• MbUnit
• MSTest
• XUnit

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

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

Answer 8

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

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

Answer 9

Преимущества/изменения VS2008 Встроенный блок тестирования Framework

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

Answer 10

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

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

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

Answer 11

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

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

Answer 12

У меня есть сообщения, что «структура файла 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 

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

Answer 13

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

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

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

Answer 14

Я бы предпочел использовать небольшую тестовую среду MS, но сейчас я придерживаюсь NUnit. Проблемы, связанные с МС, как правило, (для меня)

файла

• Shared «испытание» (бессмысленных), который должен быть поддерживается
• Тестов списков вызывают конфликты с несколькими разработчиками/VCSS
• Плохо интегрированный пользовательский интерфейс - запутанный установки, обременительный выбор теста
• нет хорошего внешнего бегун

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

Я считаю, это намного проще просто написать мои тесты и огонь up NUnitGUI или один из других передних концов (testDriven далеко далеко далеко завышен). Настройка отладки с версией командной строки также довольно проста.

Answer 15

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

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

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

Answer 16

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

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

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

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

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

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

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

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

Answer 17

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

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

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

Answer 18

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

Answer 19

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

Смотрите также:

• Microsoft Pex – Automated Unit Testing
• Unit Tests generation with Pex using Visual Studio 2010 and C# 4.0