Есть ли что-нибудь, что я могу сделать в NUnit, чего я не могу сделать в MSTest?

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

Я работаю в основном магазине Microsoft. Мы используем TFS, и у всех наших разработчиков есть подписки MSDN, включая версию Team Suite VS. Таким образом, у нас есть доступ к MSTest.

Я читал различные сравнения NUnit и MSTest, и сообщество разработчиков, похоже, в значительной степени подавляет выбор NUnit. Но приведенные причины никогда не кажутся непреодолимыми или непреодолимыми, по крайней мере, для нашей ситуации. (NUnit обновляется чаще, NUnit работает быстрее, NUnit не требует TFS и т.д.)

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

В основном я должен ответить, чтобы оправдать использование NUnit в предпочтении MSTest: есть ли что-нибудь, что я могу сделать в NUnit, что я не могу сделать с сопоставимыми усилиями в MSTest?

Ответ 1

NUnit содержит атрибут [TestCase], который позволяет выполнять параметризованные тесты. Это не существует из коробки в MSTest - это может быть сделано с помощью расширяемости.
Атрибут MsTest ExpectedException содержит ошибку, в которой ожидаемое сообщение никогда не утверждается, даже если оно ошибочно - тест пройдет.
NUnit поставляется с API Assert.Throws, позволяющим тестировать исключение на определенной строке кода вместо целого метода. Аналогичная функция существует для MSTest (реализована тем же человеком, который сделал это для NUnit), но не поставляется с MSTest.
NUnit содержит свободную версию Assert API из коробки. MSTest имеет сторонние расширения, которые делают это, но ни один из них не поставляется с MSTest.
NUnit позволяет абстрактным классам быть тестовыми приспособлениями (чтобы вы могли наследовать тестовые приборы). MsTest позволяет это, но ограничивает абстрактные классы для одной сборки.
NUnit позволяет не публичным классам быть тестовыми приборами (начиная с последней версии).
NUnit был создан SOLELY для идеи модульного тестирования. MSTest был создан для тестирования, а также немного модульного тестирования.
NUnit содержит PNunit (выполняется параллельные тесты с помощью NUnit). MSTest добавила эту возможность в Visual Studio 2010, которая настраивается через XML

Ответ 2

Рой, Букет вашей информации устарел, особенно в том, что касается 2010 года;

Nunit содержит атрибут [TestCase], который позволяет выполнять параметризованные тесты. это не существует в MSTest

Это может быть реализовано с использованием расширяемости unit test в 2010 году.

У атрибута MSTest ExpectedException есть ошибка, в которой ожидаемое сообщение никогда не утверждается, даже если оно неверно - тест пройдет.

Исправить все еще там

NUnit имеет API Assert.Throws, позволяющий тестировать исключение на определенной строке кода вместо целого метода (вы можете легко реализовать это самостоятельно, хотя)

Джим внедрил версию Assert.Throws для MSTest одновременно с первоначальной реализацией для NUnit, NUnit включил в последующие выпуски, MSTest не имеет, ее все еще можно использовать.

NUnit содержит свободную версию Assert API (как уже упоминалось - Assert.That..)

Некоторые из них реализованы третьими сторонами для MSTest

NUnit намного быстрее

См. комментарий Джейми, он успел запустить MSTest быстрее: -)

NUnit может запускать тесты в 32 и 64 бит (MSTest запускает их только в 32 бит IIRC)

Не в 2010 году встроена поддержка 64 бит.

NUnit позволяет абстрактным классам быть тестовыми приборами (чтобы вы могли наследовать тестовые приборы). MsTest не делает.

Это работает, но не через сборки, которые ограничивают его полезность.

NUnit позволяет не публичным классам быть тестовыми приборами (начиная с последней версии)

Все еще там

NUnit был создан SOLELY для идеи модульного тестирования. MSTest был создан для тестирования, а также немного модульного тестирования.

Правильно, существует много заблуждений, что MSTest такой же, как Nunit, но MSTest - это обобщенная структура.

NUnit содержит PNunit (выполняется параллельные тесты с помощью NUnit). MSTest добавляет эту способность только в 2010 году

Правильно есть настройка XML-конфигурации, которая позволяет контролировать степень parallelism.

Ответ 3

NUnit имеет более богатый API утверждения. Апи особенно элегантный (ровный, ровный), например

Assert.That(Is.Unique, myResults);  // assert: myResults is a collection of unique items

Если вы видели расширения Hamcrest для JUnit, вы узнаете этот стиль.

В нем также растет набор расширений например, тестирование производительности и отличный плагин VS.

Ответ 4

Я могу указать вам пару блогов на фрустрации с MSTest:

Справедливости ради, эти люди пытаются настроить MSTest на серверах сборки без TFS. Некоторые из их проблем не будут применяться к вашей ситуации.

Мы в основном магазин Microsoft и используем TFS для управления версиями. Однако мы используем TeamCity для непрерывной интеграции; нам это нравится, и он хорошо интегрируется с TFS. Я никогда не использовал MSTest; мы много лет используем NUnit и не видим причин для изменения.

MSTest должен иметь тесную интеграцию с Team Suite, которая (поскольку ваша компания уже заплатила за это возмутительную плату) является точкой в ее пользу.

NUnit поставляется с меньшим количеством блокировки вендора и имеет богатый API. Как указывал serg10, синтаксис Assert.That особенно силен и элегантен.

В конце концов, вы можете написать хорошие модульные тесты без всяких причудливых функций. Некоторые из них могут даже мешать (что является теорией xUnit.net). Я бы рекомендовал, чтобы ваша команда стандартизировала одну тестовую среду; не используйте код в MSTest и другой код в NUnit.

Я думаю, что писать хорошие тесты важнее, чем ваш выбор фреймворков. Рассмотрите возможность чтения Тестирование модульного тестирования: с примерами в .NET, написав несколько тестов, а затем посмотрим, подходит ли MSTest для потребностей вашей команды.

РЕДАКТИРОВАНИЕ: В приложении B к тесту тестирования устройств содержатся некоторые хорошие комментарии к Microsoft Unit Testing Framework. Он упоминает YUnit как пример того, насколько громоздким является расширение MSTest. Тем не менее, автор действительно предлагает MSTest для пользователей Team System из-за жесткой интеграции.

Ответ 5

У меня есть хороший путь между MsTest и NUnit. Вы можете использовать фреймворк MSTest для запуска теста (атрибут TestClass и атрибут TestMethod для каждого теста), но используйте API NUnit Assert.

просто выполните это:

using Microsoft.VisualStudio.TestTools.UnitTesting; 
using Assert = NUnit.Framework.Assert;

теперь вы можете использовать Assert.That(..) и все еще иметь автоматическую сборку и тестовый отчет TFS. ваш тест может быть запущен в VS, TestDriven.net или Resharper, это не имеет значения, тест завершится неудачно или пройдет правильно, а выход сбоя будет соответствовать инфраструктуре NUnit.

см. здесь: http://alsagile.com/archive/2010/03/09/stop-the-war-between-nunit-and-mstest-make-them.aspx

Ответ 6

Тестер теста MSTest не детерминированный, которого должно быть достаточно, чтобы отпугнуть вас от его использования. Я не могу последовательно запускать MSTest из TFS 2010 с помощью интегрированного тестового бегуна; он ломается с несколькими сообщениями об ошибках (и, непоследовательно) между сборками проектов и агентами сборки.
MSTest иногда (не последовательно) ломается, потому что он пропускает память - из памяти все еще происходят исключения, даже с новейшей версией Visual Studio. Обходной путь для этой проблемы ужасен.
У меня есть другие незначительные каламбуры с MSTest, и я написал в блоге кучу обходных решений для использования MSTest вообще: http://www.pseale.com/blog/TFSAsYourBuildCIServerOnlyPositiveTakeaways1Of2.aspx

Я нашел этот вопрос, поскольку я переключил нас на NUnit из MSTest, потому что мы больше не можем доверять результату нашей сборки CI из-за MSTest. Переход на NUnit позволит нам (наконец) доверять тому, что CI-сборка является реальной, а не другой ошибкой MSTest. Это реальный ответ - только с NUnit (или некоторым другим не-MSTest тестовым бегуном), мы можем доверять нашей сборке CI.

Ответ 7

Я работал над поддержкой первого класса для MSTest в TestDriven.Net 3.0. В предыдущих версиях поддержка MSTest была очень простой (казалось, мало кто использует MSTest).

Начиная с версии TestDriven.Net 3.0 Beta 2, существует довольно всесторонняя поддержка всех атрибутов, связанных с тестированием модулей MSTest. Существует даже поддержка тестов, управляемых данными, с использованием атрибута DataSource. Ваши тесты также будут выполняться со скоростью NUnit!

Если вы используете MSTest, мне было бы интересно узнать, не сработает ли какой-либо из ваших модульных тестов при выполнении с помощью TestDriven.Net 3.0 Beta 2 (или более поздней версии).

Пожалуйста, попробуйте его в своих проектах MSTest и дайте мне знать, как вы справляетесь: http://www.testdriven.net/download.aspx

ПРИМЕЧАНИЕ. Он не поддерживает атрибуты DeploymentItem или HostType. Вы можете использовать параметр проекта "Копировать в выходной каталог" вместо DeploymentItem.

Ответ 8

Вы можете изменить код в NUnit, потому что он является открытым исходным кодом. Вы не можете сделать это с помощью MSTest.

Ответ 9

См. http://fluentassertions.codeplex.com. Вы можете делать такие вещи, как

"ABCDEFGHI".Should().StartWith("AB").And.EndWith("HI").And.Contain("EF").And.HaveLength(9);

new[] { 1, 2, 3 }.Should().HaveCount(4, "because we thought we put three items in the 
collection"))

dtoCollection.Should().Contain(dto => dto.Id != null);

collection.Should().HaveCount(c => c >= 3);

dto.ShouldHave().AllPropertiesBut(d => d.Id).EqualTo(customer);

dt1.Should().BeWithin(TimeSpan.FromHours(50)).Before(dt2); 

Action action = () => recipe.AddIngredient("Milk", 100, Unit.Spoon);
action
   .ShouldThrow<RuleViolationException>()
   .WithMessage("Cannot change the unit of an existing ingredient")
   .And.Violations.Should().Contain(BusinessRule.CannotChangeIngredientQuanity

Ответ 10

@Даве Ханна MS Test доступен из коробки, поэтому один меньше компонентов беспокоится о развертывании и обновлении. Он также интегрирован с Visual Studio и другими продуктами Microsoft по дизайну.

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

Производительность. 99% тестовой производительности контролируется тестируемой системой, поэтому даже разница в производительности на 100% между двумя библиотеками приведет к неочевидной общей разнице в производительности.

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

Ответ 11

Вы можете очень легко запускать тесты NUnit в Linux с помощью Mono, и я не думаю, что вы можете сделать это с помощью тестов для MSTest.

Ответ 12

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

Второй параметр - это сообщение assert, которое отображается, когда не отображается ожидаемый тип исключения, а не ожидаемое сообщение об исключении. То есть как второй параметр в Assert.IsTrue(условие, сообщение).