NUnit по сравнению с тестовыми проектами 2008 Visual Studio для поблочного тестирования? [закрытый]

Daok назвал весь pro's тестовых проектов VS2008, вот pro's NUnit.

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

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

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

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

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

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

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

• , NUnit
• MbUnit
• MSTest
• xUnit

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

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

Совет Среды тестирования.NET и пакеты Поблочного тестирования.NET? .

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

Моя основная говядина с модульными тестами VS по NUnit является тестовым созданием VS, имеет тенденцию вводить набор сгенерированного кода для доступа члена парламента, не занимающего официального поста.

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

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

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

http://www.codeplex.com/xunit

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

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

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

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

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

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

Я получил сообщения, что "файловая структура 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

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

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

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

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

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

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

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

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

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

В MS Test слишком много атрибутов, везде - код, который выполняет настоящие тесты, представляет собой крошечные строчки, которые вы можете прочитать здесь и там. Большой беспорядок. В 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. Фреймворк Gallio. Галлио - это средство запуска тестов, как и nUnits. Единственная разница в том, что вам все равно, написали ли вы свои тесты в nUnit, msTest, xUnit или mbUnit. Все они запускаются.
3. Совместимость с nUnit. Все функции nUnit поддерживаются mbUnit. Я думаю, вам даже не нужно менять свои атрибуты (нужно будет это проверить), только вашу ссылку и использование.
4. Сборник утверждает. mbUnit имеет больше случаев Assert, включая класс CollectionAssert. По сути, вам больше не нужно писать собственные тесты, чтобы проверить, совпадают ли 2 коллекции.
5. Комбинаторные тесты. Не будет Было бы здорово, если бы вы могли предоставить два набора данных и получить тест для всех комбинаций данных. Он находится в mbUnit.

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

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