NUnit vs. MbUnit vs. MSTest vs. xUnit.net [закрито]

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

Тепер я повинен вибрати найкращий для нас. Але як? Це важливо? Яке з них є найбільш перспективним доказом і має пристойний імпульс за цим? Чи варто дбати про функції? Незважаючи на те, що xUnit здається найсучаснішим і спеціально розробленим для .NET, NUnit знову схоже на те, що широко прийнято. MSTest знову інтегрований у Visual Studio ...

Я знаю, що це стара тема, але я думав, що опублікую голосування за xUnit.NET . Хоча більшість інших згаданих рамок тестування майже однакові, xUnit.NET взяв досить унікальний, сучасний та гнучкий підхід до тестування одиниць. Це змінює термінологію, тому ви більше не визначаєте TestFixtures і Tests ... Ви вказуєте Факти та Теорії свого коду, що краще інтегрується з концепцією того, що таке тест з точки зору TDD / BDD.

xUnit.NET також надзвичайно розширюється. Класи атрибутів FactAttribute та TraitAttribute не запечатані, і вони забезпечують можливість перезапису базових методів, які дають вам великий контроль над тим, як повинні бути виконані методи, які ці атрибути прикрашають. Хоча xUnit.NET за своєю формою за замовчуванням дозволяє писати тестові класи, схожі на тестові прилади NUnit, за допомогою їх методів тестування, ви взагалі не обмежуєтесь цією формою тестування одиниць. Ви можете розширити рамки для підтримки специфікацій концерну / контексту / спостереження у стилі BDD, як зображено тут .

xUnit.NET також підтримує тестування на стилі прямо з поля з атрибутом «Теорія» та відповідними атрибутами даних. Ці вхідні дані можуть завантажуватися із excel, бази даних або навіть спеціального джерела даних, такого як документ Word (шляхом розширення атрибута базових даних.) Це дозволяє використовувати велику користь на одній платформі тестування як для одиничних тестів, так і для інтеграційних тестів, які може бути величезним у зменшенні продуктових залежностей та необхідній підготовці.

Інші підходи до тестування також можуть бути реалізовані за допомогою xUnit.NET ... можливості досить необмежені. У поєднанні з іншою дуже перспективною глузливою рамкою, Moq , вони створюють дуже гнучку, розширювану і потужну платформу для автоматизованого тестування.

NUnit, мабуть, найбільше підтримується сторонніми інструментами. Це також довше, ніж інші три.

Мене особисто не дуже хвилює тестова структура одиниць, глузування з бібліотек є важливішим для IMHO (і зафіксувати вас набагато більше). Просто виберіть один і дотримуйтесь його.

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

Я не думаю, що має велике значення, яку з інших фреймворків ви використовуєте. Переключитися з одного на інший дуже просто.

Я особисто використовую XUnit.Net або NUnit залежно від уподобань своїх колег. NUnit - найстандартніший. XUnit.Net - це найпростіший фреймворк.

Подумайте про доповнення, не замінюючи, 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 не працює добре зі змішаними проектами в C ++, тому мені довелося відмовитися

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

Я думаю, що ми залишимося на нашому нинішньому кроці, тому що він працює, і ми вже організаційно перебрали горб, але я впевнений, що бажаю, щоб у МС було переконливе пропозиція в цьому просторі, щоб ми могли трохи консолідувати та спростити наш стек розробників.

Це не велика справа, перемикатися між ними досить просто. Інтеграція MSTest теж не є великою справою, просто захоплюйте testdriven.net.

Як і попередня людина, яка сказала, вибирайте насмішкуватий каркас, мій улюблений на даний момент - Moq.