Без лишних проволочек, предположим, что вы попали в следующую ситуацию:

• у вас есть некоторый .NET проект;
• для этого проекта вы написали NUnit-тесты (либо они уже написаны);
• вам торжественно вручили Visual Studio 2008 Team System (или выше) или Visual Studio 2010 Premium (или выше) и поручили провести анализ покрытия кода тестами (aka code coverage).

Путь вам преграждает только одно маленькое «но»: Test Runner, интегрированный в Visual Studio, видит только собственные MSTest'ы, а вашему любимому NUnit'у уделяет ноль внимания и преподносит фунт презрения. Что делать?

Начиная с версии NUnit 2.5 содержит ряд замечательных атрибутов, которые смогут упростить жизнь при написании юнит(и не только) тестов, используя методологию Data Driven Tests.

Первый раз достаточно близко я познакомился с тестированием лет 5-6 назад, как раз начало моей карьеры. Тогда, я помню, мне рассказывали про покрытие кода тестами. Причем никаких Unit тестов меня не просили писать, просто говорили: “вот видишь if с тремя условиями, который ты написал, ты должен проверить все эти три условия”. Подразумевалось, что я, после того как напишу код, должен его проанализировать, и полностью протестировать обычным проходом по интерфейсу приложения. Как вам? Со временем знания в тестировании у меня немного выросли, я немного научился писать тесты. Я до сих пор не видел и не участвовал ни в одном живом проекте, написанным при помощи Test Driven Development (TDD) подхода. Основа моих знаний была в подглядывании того, как делают это коллеги в предыдущей моей конторе, чтении статей (например, у Алесандра Бындю была отличная статья “TDD для начинающих. Ответы на популярные вопросы”), просмотра пару сринкастов. Я решил покончить с безграмотностью и проникнуться темой, для этого я сел за прочтение книги The art of Unit Testing with Examples in .NET. Притом, что в текущей конторе? можно сказать, что тесты пишу только я для своего кода. Нужно быть образцом.

Недавно я попал на новый проект, с задачей создать небольшое приложение с нуля. Разговариваю с тестером:
-А как тебе новые версии поставлять?
-Можешь как все остальные на проекте, через SVN.
-То-есть ты сама билдить будешь?
-Да нет… Бинарники оттуда беру.

Оказывается, очень много программистов, даже имеющих в подписях слова вроде Senior или Superior никогда в жизни не стыкались с понятием CI, или слабо себе представляют что это такое. Не найдя отдельных публикаций на Хабре на эту тему, решил восполнить пробел, а заодно и по возможности заработать желанный инвайт.

Существует множество инструментов для автоматизации функционального тестирования приложений. С одной стороны универсальные коммерческие пакеты, настоящие монстры автоматизации – HP QuickTest Pro, SilkTest, TestComplete. С другой – специализированные или «бедные» по функциональности свободные инструменты – Selenium (web-приложения), pyWinAuto, Win32::GuiTest и т.д. Но настоящей жемчужиной среди свободных инструментов, на мой взгляд является Codeplex White Framework.

Не так давно потребовалось автоматизировать некоторое .net приложение. На работе основным инструментом для автоматизации принят QuickTest Pro, но для этого конкретного проекта он был слишком дорог: проект очень небольшой – автоматизации подлежали всего несколько операций. Встал вопром с поиском бесплатной альтернативы.

Первым бы опробован перловый Win32::GuiTest. С задачей он справился, но код скрипта получился очень уж неаккуратный – слишком тяжело его было бы в последствии поддерживать. И тут на сайте codeplex’a был обнаружен White
Он оказался настолько простым и удобным, что было решено применять его. Этот framework поддерживает большинство стандартных контролов Win32, WinForms, WPF (Silverlight), SWT. Под катом пример простой автоматизации Калькулятора Windows XP.

Модульное тестирование (unit test) очень важная часть современной разработки программного обеспечения. При тестировании web-приложений разработчики стараются охватить все аспекты работы приложения от получения запроса до выдачи результата. При разработке проектов с помощью ASP.NET MVC одним из таких моментов является механизм маршрутизации. Тестирование маршрутов обычно приносило немало головной боли, заставляя разработчика писать много сопутствующего кода. В этой заметке я покажу как используя пару инструментов можно упростить тестирование маршрутов до минимума.

Заглянув на официальный сайт NUnit, обнаружил интересную новинку в версии 2.5 этой замечательной библиотеки.

Тестировать методы на различных входящих данных стало очень удобно:

[TestCase(12, 3, 4)]
[TestCase(12, 2, 6)]
[TestCase(12, 4, 3)]
[TestCase(12, 0, 0, ExpectedException = typeof(System.DivideByZeroException),
TestName = “DivisionByZeroThrowsExceptionType”)]
[TestCase(12, 0, 0, ExpectedExceptionName = “System.DivideByZeroException”,
TestName = “DivisionByZeroThrowsNamedException”)]
public void IntegerDivisionWithResultPassedToTest(int n, int d, int q)
{
Assert.AreEqual(q, n / d);
}

К сожалению если Вы запускаете тесты через решарпер, пока эта функциональность не для Вас. Пока это работает только если запускать тесты непосредственно через сам NUnit (консольный или gui).

официальная документация

После установки Asp.net mvc framework ставится ряд template в VS студию. И теперь например при создании проекта «asp.net mvc Web application», в самом начале есть возможность выбрать какой именно test framework используется для разработки. Но к сожалению там всего один пункт для выбора. Уже сейчас есть возможность установить кучу расширений. Так как я для разработки использую nUnit, то найти такой «плагин», было бы не плохо.

Качаем небольшой архив с двумя шаблонами:

• NUnitDemo
• NUnitAndRhinoMocks

В архиве находим либо NUnitDemo.zip либо, NUnitAndRhinoMocks.zip и NUnitAndRhinoMocks.reg и NUnitDemo.reg.
Копируем их в "\Microsoft Visual Studio 9.0\Common7\IDE\ProjectTemplates\CSharp\Test\1033\"
Далее запускаем «devenv /setup».
Теперь при создании проекта можно дополнительно выбрать еще несколько шаблонов.

Всем привет! Хабраюзер shai_xylyd написал статью про аспекты тестирования, где им были рассмотрены некоторые понятия и ценности TDD. В частности, он упомянул очень интересный способ создания первичных юнит-тестов — когда функциональный код пишется совместно с кодом юнит-теста, чем меня очень заинтриговал.

Дело в том, что я (как программист), нахожусь в состоянии переходного процесса между «классической» разработкой и разработкой test-driven, поэтому всякими способами ищу возможности упростить и сделать более естественной последнюю. После пары приседаний, сразу включиться в методику shai_xylyd не сумел. Начал переписку с автором статьи, где он натолкнул меня на мысль подойти к решению с математической точки зрения. Идея в том, чтобы воспользоваться функциональным пространством среды программирования и «разложить» написание юнит-теста на составляющие. После чего сделать выводы.