NUnit против MbUnit против MSTest против xUnit.net [закрыто]

390

Существует довольно много платформ для тестирования модулей для .NET. Я нашел это небольшое сравнение функций: http://xunit.github.io/docs/comparisons.html

Теперь я должен выбрать лучший для нас. Но как? Это имеет значение? Какой из них наиболее перспективен на будущее и имеет достойный импульс? Должен ли я заботиться о функциях? В то время как xUnit кажется самым современным и специально разработанным для .NET, NUnit снова, кажется, широко принят. MSTest снова уже интегрирован в Visual Studio ...

bitbonk
источник
11
Эта сравнительная таблица устарела годами. Например, в NUnit также есть Assert.Throws и т. Д., И все в таблице утверждений является старым API. Новый свободный синтаксис Assert.That (..., Is ....) намного приятнее и уже давно существует.
Джим Купер
11
Знаете ли вы какие-либо таблицы, которые являются более современными?
bitbonk
1
Конец 2013, переехал с xUnit.net => NUnit. Также обратите внимание, что xUnit.NET (проект)! = XUnit (категория, членом которой является NUnit)
DeepSpace101
3
@ Сид, почему ты перешел с xUnity.net => NUnit?
Александр Логгер
2
Аналогичный вопрос задавался в 2014 Visual Studio 2013 MSTest против NUnit
Майкл

Ответы:

197

Я знаю, что это старая ветка, но я решил опубликовать голосование за xUnit.NET . Хотя большинство других упомянутых сред тестирования в значительной степени одинаковы, xUnit.NET использует довольно уникальный, современный и гибкий подход к модульному тестированию. Это меняет терминологию, поэтому вы больше не определяете TestFixtures и Tests ... вы указываете факты и теории о вашем коде, что лучше интегрируется с концепцией того, что такое тест с точки зрения TDD / BDD.

xUnit.NET также чрезвычайно расширяемо. Его классы атрибутов FactAttribute и TraitAttribute не запечатаны и предоставляют переопределяемые базовые методы, которые дают вам большой контроль над тем, как должны выполняться методы, которые украшают эти атрибуты. Хотя xUnit.NET в его форме по умолчанию позволяет вам писать тестовые классы, которые похожи на тестовые приборы NUnit с их методами тестирования, вы не ограничены этой формой модульного тестирования вообще. Вы можете расширить платформу для поддержки спецификаций BDD-типа «Забота / Контекст / Наблюдение», как показано здесь .

xUnit.NET также прямо из коробки поддерживает тестирование в стиле соответствия с помощью своего атрибута Theory и соответствующих атрибутов данных. Подходящие входные данные могут быть загружены из Excel, базы данных или даже из пользовательского источника данных, такого как документ Word (путем расширения базового атрибута данных). Это позволяет использовать единую платформу для тестирования как модульных, так и интеграционных тестов, которые может быть огромным в снижении зависимости продукта и необходимого обучения.

Другие подходы к тестированию также могут быть реализованы с xUnit.NET ... возможности довольно безграничны. В сочетании с другой перспективной инфраструктурой Moq , они создают очень гибкую, расширяемую и мощную платформу для реализации автоматического тестирования.

jrista
источник
35
Хотя это было правдой год назад, с тех пор NUnit добавил большинство рассматриваемых атрибутов. В NUnit вы можете написать тесты в любом случае.
Марк Левисон
8
Дело не столько в том, какие атрибуты доступны, сколько в том, как их можно использовать. xUnit.NET изначально разрабатывался как очень гибкая и расширяемая среда, которая не привязывала вас к какому-либо конкретному методу тестирования, и не требовала от вас регулярно обновлять базовую среду для получения новейших возможностей.
Ириста
9
1. Немного разные имена атрибутов не будут иметь большого значения. 2. NUnit был расширяемым и продолжает быть расширяемым: 3. параметры строки данных для тестов поддерживаются в nunit. Некоторое время назад их поддерживали в расширении :) 4. Nunit в сочетании с Moq создает то же самое. 5. Для BDD, я бы сказал, specflow, который легко интегрируется со многими средами модульного тестирования.
График
8
Мне нравится звук xUnit, однако он имеет документацию zilch :(
Полковник Panic
10
xUnit не имеет никакой документации вообще! Например: попробуйте найти то, что Traitдействительно делает, или если вы можете сгруппировать различные тесты в рамках одного родительского теста (например, все в testsпределах testfixture). nUnit создает отличное иерархическое представление вместо плоского представления тестов xUnit. Плюс номенклатура не имеет смысла - факты и теория? Быть реалистичным! Это лучше называть тестами и данными.
DeepSpace101
134

NUnit, вероятно, наиболее поддерживается сторонними инструментами. Это также было дольше, чем остальные три.

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

Александр Кожевников
источник
3
какой твой лучший макет библиотеки?
dplante
31
Мне нравится Moq, RhinoMocks тоже хорошо.
Александр Кожевников
5
Также стоит проверить Пекса и Родинок, особенно полезна для насмешек.
Чарльз Пракаш Дасари
4
MSPec с FakeItEasy ... делая тесты более читабельными
Роби
5
MSpec с NSubstitute и AutoFixture - мой выбор.
Даниэль Хилгарт
108

Я бы не пошел с MSTest. Хотя это, вероятно, самое перспективное доказательство наличия фреймворков с Microsoft, это не самое гибкое решение. Он не будет работать в одиночестве без некоторых хаков. Поэтому запустить его на сервере сборки, отличном от TFS, без установки Visual Studio сложно. Визуальный тестовый прогон на самом деле медленнее, чем Testdriven.Net + любой другой фреймворк. А поскольку выпуски этой среды привязаны к выпускам Visual Studio, обновлений меньше, и если вам приходится работать со старыми VS, вы привязаны к более старому MSTest.

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

Я лично использую XUnit.Net или NUnit в зависимости от предпочтений моих коллег. NUnit является самым стандартным. XUnit.Net является самой простой структурой.

Mendelt
источник
36
Меня тащили ногами и кричали к тому же выводу. Я действительно хотел использовать MSTest из-за его интеграции с Visual Studio, но это также и его слабость. Мне нужно запустить тесты на сервере сборки не от Microsoft, и я никак не могу установить Visual Studio на него, чтобы получить его. Жаль, что Microsoft выпускает отличные инструменты, а затем делает их практически недостижимыми.
Тим Лонг
11
+1 за вызов ужаса, который есть MSTest. В конце концов, не имеет значения, какую платформу модульного тестирования вы используете, так же долго, как это не MSTest
Майк Муни
21

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

Например, я использую xUnit с MSTest. Добавьте ссылку на сборку xUnit.dll и просто сделайте что-то подобное. Удивительно, но это просто работает!

using Microsoft.VisualStudio.TestTools.UnitTesting;
using Assert = Xunit.Assert;  // <-- Aliasing the Xunit namespace is key

namespace TestSample
{
    [TestClass]
    public class XunitTestIntegrationSample
    {
        [TestMethod]
        public void TrueTest()
        {
            Assert.True(true);  // <-- this is the Xunit.Assert class
        }

        [TestMethod]
        public void FalseTest()
        {
            Assert.False(true);
        }
    }
}
Мэтт Крауч
источник
Этот метод может также работать для NUnit, MBUnit или других сред тестирования, упомянутых в других ответах, но я не пробовал их.
Мэтт Крауч
1
Как вы думаете, я мог бы получить параметризованные тесты для работы с MSTest с этим подходом, Мэтт?
DevDave
@DevDave Нет. В своем примере он просто использовал класс из другой сборки. Если вам нужны параметризованные тесты, вам понадобится другая среда тестирования, специально созданная для расширения MSTest.
zoran404
3
Suprisingly, it just works!Вы только что вызвали статическую функцию из другой сборки. Почему вы удивлены тем, что это работает? Также, если вам просто нужны утверждения, почему бы не использовать сборку, специально созданную для этого?
zoran404
9

Nunit плохо работает с проектами смешанного режима в C ++, поэтому мне пришлось отказаться от него

Эрик
источник
3
Я не горжусь этим ответом, но я отказался от модульного тестирования для этого проекта. Я прибег к написанию большого количества процедур проверки для обнаружения ошибок во время выполнения
Эрик
2
Я надеялся использовать NUnit в смешанном режиме, но также нашел его неадекватным, в конце концов, я выбрал googletest, который является отличной платформой для модульного тестирования C ++ и очень прост в настройке.
чилитом
8

Это не имеет большого значения в маленьком / личном масштабе, но это может быстро стать большим делом в большем масштабе. Мой работодатель - крупный магазин Microsoft, но я не буду / не могу покупать Team System / TFS по ряду причин. В настоящее время мы используем Subversion + Orcas + MBUnit + TestDriven.NET, и это работает хорошо, но получение TD.NET было огромной проблемой. Чувствительность версии MBUnit + TestDriven.NET также является большой проблемой, и наличие еще одной коммерческой вещи (TD.NET) для юридического контроля и закупок для обработки и управления не является тривиальной задачей. Моя компания, как и многие другие, полна и довольна моделью подписки MSDN, и она просто не используется для обработки разовых закупок для сотен разработчиков. Другими словами, полностью интегрированное предложение MS, хотя и не всегда лучшее, что есть, на мой взгляд, является существенной прибавочной стоимостью.

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

user8133
источник
2
У ReSharper есть привлекательное предложение в этом пространстве!
Белка
7
Ваш ответ любопытен и кажется противоречивым. Вы говорите, что являетесь крупным магазином Microsoft, но не будете использовать TFS (в этом вся суть - вы не получите преимущества вертикальной интеграции без нее) и используете модель подписки MSDN, но используете не MS подход. Я потерян, если честно. Ну устаревший ответ, к сожалению.
nicodemus13
6

Это не имеет большого значения, довольно легко переключаться между ними. Интеграция MSTest также не имеет большого значения, просто зайдите на testdriven.net.

Как и предыдущий человек сказал, выбери насмешливые рамки, мой любимый на данный момент - Moq.


источник