Я буду запускати новий проект на роботі і хочу взяти участь у тестуванні. Ми будемо використовувати VS 2008, C # та речі ASP.NET MVC. Я дивлюсь на використання або NUnit, або вбудовані тестові проекти, які має VS2008, але я відкритий для дослідження інших пропозицій. Чи одна система краща за іншу чи, можливо, простіша у використанні / розумінні, ніж інша? Я хочу, щоб цей проект було створено як "найкращу практику" для наших зусиль з розвитку.
Дякуємо за будь-яку допомогу та пропозиції !!
Відповіді:
Даок назвав усіх професіоналів тестових проектів VS2008, ось професіонали NUnit.
Рамка для тестування одиниць насправді не має великого значення, оскільки ви можете конвертувати тестові класи за допомогою окремих файлів проекту та умовної компіляції (наприклад, VS-> NUnit):
#if! NUNIT використання Microsoft.VisualStudio.TestTools.UnitTesting; #else використання NUnit.Framework; використовуючи TestClass = NUnit.Framework.TestFixtureAttribute; використовуючи TestMethod = NUnit.Framework.TestAttribute; використовуючи TestInitialize = NUnit.Framework.SetUpAttribute; використовуючи TestCleanup = NUnit.Framework.TearDownAttribute; використовуючи TestContext = System.String; використовуючи DeploymentItem = NUnit.Framework.DescriptionAttribute; #endif
Плагін TestDriven.Net приємний і не дуже дорогий ... Маючи лише звичайний VS2008, ви повинні знайти тест зі свого тестового класу чи списку тестів. З TestDriven.Net ви можете запустити свій тест безпосередньо з класу, який ви тестуєте. Зрештою, тестовий пристрій повинен бути простим у обслуговуванні та поблизу розробника.
Переваги / зміни рамки тестування вбудованого модуля VS2008
Я використовую NUnit вже 2 роки. Все нормально, але я мушу сказати, що система Unit у VS є досить приємною, оскільки вона знаходиться всередині Gui і може легше зробити тест на приватну функцію, не маючи возитися. Крім того, Unit Testing VS дозволяє вам покривати та інші речі, які NUnit самостійно не може зробити.
Одне незначне роздратування тестувальної рамки Visual Studio полягає в тому, що це створить безліч тестових файлів, які, як правило, захаращують ваш каталог проектів - хоча це не така вже й велика угода.
Крім того, якщо вам не вистачає плагіна, такого як TestDriven.NET, ви не можете налагоджувати тести NUnit (або MbUnit, xUnit тощо) у середовищі Visual Studio, як це можна зробити з тестовою рамкою Microsoft VS, в яку вбудовано.
Трохи поза темою, але якщо ви переходите на NUnit, я можу порекомендувати використовувати ReSharper - це додає деякі кнопки до інтерфейсу VS, які полегшують запуск та налагодження тестів всередині IDE.
Цей огляд трохи застарів, але пояснює це детальніше:
XUnit - це ще одна можливість для проекту «greenfield» Він має, можливо, інтуїтивніший синтаксис, але насправді не сумісний з іншими рамками.
Моя основна яловичина з тестами VS-модуля над NUnit - це тест VS, який прагне ввести купу згенерованого коду для доступу приватного члена.
Деякі можуть захотіти перевірити свої приватні методи, інші - ні, це вже інша тема.
Мене хвилює, коли я пишу одиничні тести, їх слід надзвичайно контролювати, тому я точно знаю, що я тестую і як саме тестую. Якщо є код, автоматично створений, я втрачаю частину цього права власності.
Я зробив декілька TDD, використовуючи і те, і інше (можливо, я трохи німий) nUnit, здається, набагато швидше і простіше для мене. А коли я багато кажу, я багато чого означаю.
У MS Test дуже багато атрибутів, скрізь - код, який робить справжні тести, - це крихітні рядки, які ви можете прочитати тут і там. Великий безлад. У nUnit код, який робить тест, просто домінує над атрибутами, як це слід робити.
Крім того, в nUnit вам просто потрібно натиснути на тести, які ви хочете запустити (лише один? Всі тести, що охоплюють клас? Збірка? Рішення?). Один клік. А вікно чисте і велике. Ви отримуєте чіткі зелені та червоні вогні. Ви справді знаєте, що відбувається за один погляд.
У VSTS список тестів застряг у нижній частині екрана, він невеликий і некрасивий. Ви повинні подивитися двічі, щоб знати, що сталося. І ви не можете запустити лише один тест (ну, я цього ще не дізнався!).
Але я можу помилятися, звичайно - я просто прочитав близько 21 публікації в блозі на тему "Як зробити простий TDD за допомогою VSTS". Я мав би прочитати більше, ви праві.
Для nUnit я прочитав один. І я TDDing того ж дня. З веселощами.
До речі, я зазвичай люблю продукти Microsoft. Visual Studio - це справді найкращий інструмент, який розробник може придбати - але управління TDD та робочими елементами в Visual Studio Team System - це насправді.
Всього найкращого. Сильвайн.
У мене з'явилися повідомлення про те, що "файлова структура 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Або будь-яке інше перетворення ... :-) Це використання тут просто псевдонім для компілятора.
Спершу я хочу виправити неправильне твердження: ви можете запустити msTest поза візуальною студією за допомогою командного рядка. Хоча кілька інструментів CI, такі як TeamCity, мають кращу підтримку NUnit (можливо, це зміниться, коли msTest стане більш популярним). У моєму теперішньому проекті ми використовуємо обидва, і єдина велика різниця, яку ми виявили, це те, що mstest завжди працює як 32-бітний, а NUnit працює як 32-бітний або 64-бітний тест, що має значення лише в тому випадку, якщо ваш код використовує нативний код, який залежить від 32/64.
Я почав з MSTest, але перейшов з однієї простої причини. MSTest не підтримує успадкування методів випробувань від інших збірок.
Я ненавидів ідею написати один і той же тест кілька разів. Особливо у великому проекті, де методи тестування можуть легко потрапити до 100-х тестів.
NUnit робить саме те, що мені потрібно. Єдине, чого не вистачає у NUnit - це Visual Studio Addin, який має відображати статус червоного / зеленого (як VSTS) кожного тесту.
Якщо ви розглядаєте або MSTest, або nUnit, я рекомендую вам переглянути mbUnit. Мої причини такі
Я спочатку зібрав mbUnit через його [RowTest ....] функціонал, і не знайшов жодної причини повернутися назад. Я перемістив усі свої активні тестові набори з nUnit, і ніколи не оглядався. Відтоді я перетворив дві різні команди розвитку на користь.
Наскільки мені відомо, в наші дні є чотири рамки для тестування одиниць з .NET
NUnit завжди був попереду, але розрив зменшився за останній рік. Я все ще віддаю перевагу NUnit сам, тим більше, що вони додавали плавний інтерфейс, який час назад робить тести дуже читабельними.
Якщо ви тільки починаєте з тестування одиниць, це, ймовірно, не має великої різниці. Як тільки ви зробите швидкість, ви зможете оцінити, яка рамка найкраща для ваших потреб.
Мені не подобається VS-вбудована система тестування, тому що вона змушує вас створити окремий проект на відміну від того, щоб ваші тести були частиною проекту, який ви тестуєте.
По суті, MSTest по суті є NUnit злегка переробленим, маючи кілька нових функцій (таких як налаштування збірки та виїзд, а не лише кріплення та рівень тесту) та відсутні деякі кращі біти (наприклад, новий синтаксис обмеження 2,4). NUnit зріліший, і більше підтримка для нього з боку інших постачальників; і звичайно, оскільки він завжди був безкоштовним (тоді як MSTest лише перетворився на Професійну версію 2008 року, до цього він був набагато дорожчим SKU), більшість проектів ALT.NET використовують його.
Сказавши це, є деякі компанії, які неймовірно не хочуть використовувати те, що не має на ньому етикетки Microsoft, і тим більше код OSS. Отже, наявність офіційної рамки тестування для MS може бути мотивацією, що цим компаніям потрібно пройти тестування; і будьмо чесними, тестування має значення, а не те, яким інструментом ви користуєтесь (і використовуючи вищезгаданий код Туомаса Гіетанена , ви майже можете зробити свою тестову рамку взаємозамінною).
SetUpі TearDownатрибутів: jamesnewkirk.typepad.com/posts/2007/09/why-you-should-.html
З випуском в .NET 4.0 системи Код контрактів і наявністю статичної перевірки вам теоретично потрібно буде записати менше тестових випадків, і інструмент на зразок Pex допоможе визначити ці випадки. Пов’язавши це з дискусією, якщо вам потрібно менше робити тести на підрозділах, оскільки у ваших контрактах покривається хвіст, то чому б просто не продовжувати та використовувати вбудовані шматки, оскільки це одна менша залежність для управління. У ці дні я все про простоту. :-)
Дивитися також:
Я вважаю за краще використовувати невелику тестову рамку MS, але поки що я дотримуюся NUnit. Проблеми з МС, як правило, (для мене)
Caveats - Якби я тестував сайт aspx, я б обов'язково використовував MS - Якщо я розробляв соло, то й MS буде добре - Якби я мав обмежену майстерність і не зміг налаштувати NUnit :)
Мені набагато простіше просто написати свої тести і запустити NUnitGUI або один з інших передніх кінців (testDriven далеко далеко завищений). Налаштування налагодження з версією командного рядка також досить просто.