Тестовые проекты NUnit и Visual Studio 2008 для модульного тестирования? [закрыто]

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

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

Даок назвал всех профессионалов тестовых проектов VS2008, вот профессионалы NUnit.

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

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

 #if! NUNIT
  использование Microsoft.VisualStudio.TestTools.UnitTesting;
 #else
  используя 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 вы можете запустить свой тест непосредственно из класса, который вы тестируете. В конце концов, юнит тест должен быть прост в обслуживании и находиться рядом с разработчиком.

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

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

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

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

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

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

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

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

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

http://www.codeplex.com/xunit

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

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

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

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

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

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

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

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

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

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

Всего наилучшего. Сильвен.

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

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

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

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

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

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

.NET Testing Framework Советы и пакеты .NET Unit Testing? ,

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

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

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

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

• NUnit
• MbUnit
• MSTest
• XUnit

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

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

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

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

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

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

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

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

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

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

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

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