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

254

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

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

Райан Скарин
источник

Ответы:

99

Даок назвал всех профессионалов тестовых проектов 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.
Mendelt
источник
19
Разве вы не можете просто использовать mstest.exe для запуска тестов MSTest вне IDE?
Филипп Уэллс
13
Монахиня, имеющая насмешливую основу, не является большим преимуществом. Я использовал проекты модульных тестов VS 2008 с платформой Moq, в которой используется новый подход, использующий деревья выражений LINQ: code.google.com/p/moq
DSO
5
Еще один плюс для Nunit, для меня в любом случае, заключается в том, что Resharper имеет очень приятный пользовательский интерфейс, который намного быстрее, чем компоненты тестирования VS. Он даже связывает трассировку стека неудачных тестов с вашим кодом.
Джефф Путц
7
Модульное тестирование включено в профессиональную версию VS 2008.
user179700
3
@Jeff Putz: Resharper также может запускать модульные тесты Visual Studio даже вне тестового проекта.
Пол Руане
64

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

Туомас Хиетанен
источник
12
Я отказался от этого, потому что NUnit имеет более богатый синтаксис, чем MSTest, что означает, что вы можете перейти от MSTest -> NUnit, но не наоборот, если вы не будете ОЧЕНЬ осторожны. История показывает, что по крайней мере один из нас - нет.
Томас Эйд
2
Я согласен с Томасом. Это будет работать при условии, что вы используете самые основные операторы assert, но модель ограничений NUnit очень мощная и достаточно веская, чтобы выбрать NUnit вместо MSTest.
Mark
Я полагаю, что этот подход используется группой MS Pattern и практикой в ​​тестах EntLib.
robi-y
1
@ Дэн Нили, если вы тестируете рядовых, вы делаете это неправильно :(
JDPeckham,
2
@JDPeckham Я не говорю, что соглашения о том, что следует / не следует делать с помощью инструмента, не важны, но, в конце концов, выполнение работы - самая важная вещь. Если это означает, что гвоздя нужно топать гвоздем по обратной стороне, потому что производители инструментов не продают молотки, то производителям топориков просто придется смириться с возмущением.
Дэн играет с Firelight
34

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

  1. Версия 2008 года теперь доступна в профессиональных выпусках (до того, как потребовались дорогие версии VS, это только для модульного тестирования разработчиков), что оставило многим разработчикам единственный выбор открытых / внешних платформ тестирования.
  2. Встроенный API поддерживается одной компанией.
  3. Используйте те же инструменты для запуска и создания тестов (вы можете запустить их с помощью командной строки также MSTest)
  4. Простой дизайн (не предоставляется Mock Framework, но это отличная отправная точка для многих программистов)
  5. Предоставлена ​​долгосрочная поддержка (я до сих пор помню, что случилось с nDoc, я не хочу связываться с инфраструктурой тестирования, которая может не поддерживаться в течение 5 лет, но я по-прежнему считаю, что nUnit - отличная платформа).
  6. Если в качестве бэкэнда используется сервер Team Foundation, вы можете простым способом создавать рабочие элементы или ошибки с данными о неудачных тестах.
Simara
источник
4
Я действительно думаю, что он по-прежнему говорит о том, как Microsoft рассматривает тестирование, что оно НЕ в стандартной версии, просто Professional и выше.
J Wynia
Согласитесь, хотелось бы увидеть его в стандарте и выше. В экспресс-версиях это будет излишним для новичка.
Симара
1
@J Wynia: Чтение их решения включить его только в Professional и выше, когда они говорят что-то об их взгляде на тестирование, означает слишком много. Это скорее деловое решение, чем философское.
Джейсон
Тестирование @Simara должно быть присуще жизненному циклу разработки. Это должно быть предоставлено в экспресс-изданиях.
Пасха
33

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

Патрик Дежарден
источник
44
Вы не должны касаться своих рядовых. Шутка в сторону, одна мысль о том, что все, что вам нужно, - это ваши публичные методы. Вызов всех ваших открытых методов должен вызывать все ваши частные методы. Если закрытый метод не вызывается через публичный, закрытый метод является избыточным.
Ливен Керсмакерс
7
@Lieven: если вы тестируете рядовых пользователей, то на самом деле вы проводите интеграционный тест, а не модульный тест. (Конечно, я не фанат TDD, и я, вероятно, просто протестировал бы публику ... но я чувствую, что помогаю начать бой)
Мэтью Уайтед
11
@ Мэтью, интеграционное тестирование - это тестирование двух или более модулей вместе. Тестирование частных методов - это просто (огромное) нарушение инкапсуляции и может привести к хрупким модульным тестам, которые должны изменяться при каждом изменении реализации.
Омер Раухвергер
3
Вы также можете использовать [assembly: InternalsVisibleTo (...)] с директивой компилятора, чтобы убрать ее при создании RTM-сборки.
Иэн Галлоуэй
1
Я все время прикасаюсь к своим сотрудникам :) Я думаю, что имеет смысл специально тестировать частных пользователей, чтобы избежать лишних затрат при тестировании вызывающих абонентов, которые требуют много сложных настроек.
Crackerjack
14

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

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

Долгопят
источник
3
Вы можете отлаживать тестирование NUnit в Visual Studio 2005.
Джейсон Шорт,
Вы также можете отлаживать xunit, но неясно, как это настроить (страница свойств)
annakata
1
Вы можете легко отладить NUnit, подключив отладчик к запущенному процессу NUnit, как сказал Grimus. Никакого реального недостатка здесь нет.
Анна Шуесслер
1: Количество тестов, настраиваемых в настройках VS - я установил его на один. 2: согласен с комментариями выше - возможно, но неудобно, 3: в целом, я предпочитаю встроенную среду тестирования VS.
Рауль Рубин
14

Немного не по теме, но если вы используете 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

Ричард Эв
источник
С плагином Gallio для R # вы также можете запустить MSTest.
Kjetil Klaussen
CodeRush помещает значки в тесты прямо в коде, чтобы вы могли запустить один тест или все тесты в классе или в пространстве имен. Смотрите здесь: community.devexpress.com/blogs/markmiller/archive/2009/11/16/…
Райан Ланди
Решарпер также проведет тесты MSTest.
Дж.Д. Пекхэм,
11

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

http://www.codeplex.com/xunit

Бен Фултон
источник
11

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

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

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

Ян Саттл
источник
11

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

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

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

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

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

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

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

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

Сильвен Родриг
источник
9

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

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

Туомас Хиетанен
источник
1
Я не понимаю, что вы здесь говорите.
PositiveGuy
нет установки / снятия уровня прибора :( или они предполагают, что мы используем ctor и dtor?
JDPeckham
9

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

Dror Helper
источник
8

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

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

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


источник
7

Если вы рассматриваете 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 и больше не оглядывался назад. С тех пор я превратил две разные команды разработчиков в преимущества.

AlSki
источник
6

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

  • NUnit
  • MbUnit
  • MSTest
  • XUnit

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

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

gilles27
источник
6

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

Джин Мительман
источник
3
На самом деле вы можете обмануть Visual Studio, вручную отредактировав файлы проекта и добавив значения ProjectTypeGuids, которые он использует для идентификации тестовых проектов: & lt; ProjectTypeGuids & gt; {3AC096D0-A1C2-E12C-1390-A8335801FDAB}; {FAE04EC0-301F-11D3- BF4B-00C04F79EFBC} & л; / ProjectTypeGuids & GT;
Пол Руане
5

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

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

Дэвид Кивини
источник
Я люблю синтаксис contraint NUnit, но я думаю , вы должны прочитать о SetUpи TearDownатрибуты: jamesnewkirk.typepad.com/posts/2007/09/why-you-should-.html
Nobody
4

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

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

Норман Н
источник
3

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

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

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

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

Эндрю Бакер
источник
Прямо сейчас я использую Resharper для запуска MS Tests, поэтому я не против их. Я предпочитаю CodeRush + RefactorPro, хотя это не то, что мы здесь используем. Возможно, сейчас у них есть достойный бегун для MS Test.
Эндрю Бакер