NUnit против MbUnit против MSTest против xUnit.net

Ответ 1

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

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

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

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

Ответ 2

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

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

Ответ 3

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

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

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

Ответ 4

Рассмотрите возможность добавления, не заменяя 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);
        }
    }
}

Ответ 5

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

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

Ответ 6

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

Ответ 7

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

Как и предыдущий, человек сказал, что он насмехается над картой, моим фаворитом в данный момент является Moq.