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

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

Кроме того, модульное тестирование Visual Studio позволяет выполнять покрытие и другие вещи, которые не может выполнить только NUnit.

Даок назвал всех профи тестовых проектов Visual Studio 2008. Вот плюсы NUnit.

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

Фреймворк модульного тестирования на самом деле не имеет большого значения, потому что вы можете конвертировать тестовые классы с отдельными файлами проекта и условной компиляцией (например, Visual Studio → 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 хорош и не очень дорог ... Имея только простую Visual Studio 2008, вам нужно найти тест из своего тестового класса или списка тестов. С помощью TestDriven.Net вы можете запускать свой тест прямо из класса, который вы тестируете. В конце концов, модульные тесты должны быть простыми в обслуживании и находиться рядом с разработчиком.

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

Сначала я хочу исправить неправильный оператор: вы можете запустить MSTest вне Visual Studio с помощью командной строки. Хотя некоторые инструменты CI, такие как TeamCity, лучше поддерживают NUnit (вероятно, изменится, когда MSTest станет более популярным).

В моем текущем проекте мы используем и то, и другое, и с единственной большой разницей мы обнаружили, что MSTest всегда работает как 32-битный, а NUnit - как 32-битный или 64-битный тесты, что имеет значение только в том случае, если ваш код использует собственный код, который зависит от 32/64 бит.

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

• NUnit
• MbUnit
• MSTest
• xUnit

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

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

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

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

Преимущества / изменения встроенной среды модульного тестирования Visual Studio 2008:

1. Версия 2008 года теперь доступна в профессиональные издания (до этого требовались дорогие версии Visual Studio и это только для модуля разработчика тестирование), что оставило много разработчикам с единственным выбором Фреймворки открытого / внешнего тестирования.
2. Встроенный API, поддерживаемый одной компанией.
3. Используйте те же инструменты для запуска и создания тестов (вы можете запускать их с помощью командной строки также MSTest).
4. Простой дизайн (предоставляется без фиктивного фреймворка, но это отличная отправная точка для многих программистов).
5. Предоставляется долгосрочная поддержка (я до сих пор помню, что случилось с NDoc, и я не хочу брать на себя обязательства по тестовой среде, которая может не поддерживаться через пять лет, но я все же считаю NUnit отличным фреймворком).
6. Если в качестве серверной части используется Team Foundation Server, вы можете простым способом создавать рабочие элементы или ошибки с данными неудачного тестирования.

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

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

Использование ReSharper как неотъемлемой части вашего набора инструментов TDD

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

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

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

 #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

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

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

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

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

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

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

Предостережения

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Microsoft Pex - автоматическое модульное тестирование
• Генерация модульных тестов с помощью Pex с использованием Visual Studio 2010 и C# 4.0