Будущие соображения для NUnit и NAnt

Question

В течение .NET v1 дней я без особого успеха пытался убедить коллег выработать привычки, основанные на тестировании и автоматизированной сборке, с использованием дополнительных инструментов NUnit и NAnt. Когда в дело вступили .NET Framework 2.0 и Visual Studio 2005 Team Suite, я смог «заставить» свою команду писать тесты и проводить визуальное тестирование прямо в Visual Studio. Кроме того, мне удалось настроить файлы проекта с помощью дополнительных задач MSBuild для более полной автоматизации сборки.

Конечно, это не означает, что Microsoft поставила совершенные системы, но я считаю, что они сделали это в правильном направлении. Со всеми этими функциями, встроенными прямо в среду и продукты и ставшими «родными», стало легче подталкивать разработчиков к лучшим методам разработки.

Давно забыв о вариантах с открытым исходным кодом (которые мне не хватает), мне интересно, какое ценностное предложение поддерживают нынешние воплощения NUnit и NAnt? В каком случае можно спорить на этом этапе, чтобы убедить команду , а не использовать MSBuild или MSTest?

Разъяснение : Моя компания - чистый Microsoft SI. Выпуски Visual Studio Team Suite, Database Professional Edition, TFS и тому подобное доступны для нашего использования. Мы не используем Visual Studio Professional или более позднюю версию.

Answer 1

MSBuild - довольно хороший инструмент для сборки. Я использовал его в сочетании с NAnt и Cruisecontrol.Net пару раз. NAnt вместе с расширениями вклада NAnt кажется немного более гибким в обработке инструментов OSS, таких как NUnit, NCover и т. Д., В то время как тот факт, что MSBuild может создавать VS-решения, является большим плюсом для этого. Я обнаружил, что самый простой способ создания сценариев сборки - это использовать как NAnt для вызова различных частей сборки (build, fxcop, test, cover и т. Д.), Так и MSBuild для фактического построения.

Мне не так много хорошего сказать о MSTest. Это медленно и громоздко для установки, например, на сервере сборки. Он не очень гибкий и имеет всевозможные «дополнения», которые кажутся более ориентированными на интеграционное тестирование, чем на модульное тестирование. Я обнаружил, что легкий вес XUnit.Net, MBUnit или NUnit гораздо лучше подходит для модульного тестирования. Здесь важна скорость, вы хотите часто запускать тесты для быстрой обратной связи о последствиях ваших изменений в коде. Переносимость тоже важна. Вы хотите, чтобы тесты выполнялись везде без какой-либо настройки и взлома, как это необходимо для MSTest на компьютере, на котором не установлена ​​командная система. Хотя модульное тестирование не является новым, там все еще идет большая разработка. Лучшие практики сильно меняются, как и инструменты. Я не хочу быть привязанным к инструменту, который обновляется каждые несколько лет с помощью Visual Studio. Каждый из трех инструментов модульного тестирования OSS .net настроен на расширение. MSTest нет (насколько я видел).

Answer 2

На мой взгляд, NUnit является стандартом де-факто для модульных тестов в .NET. Это бесплатно, и вы можете легко написать тесты в любой редакции Visual Studio. Если бы MS сделала MS Test доступным в VS 2005 Pro (как это было в VS 2008 Pro), он, возможно, уже вступил во владение - но я думаю, что уже слишком поздно.

Я считаю, что ReSharper в основном необходим для Visual Studio, и в него входит отличный тестовый прогон, который отлично работает с NUnit. Если я разрабатываю проект с открытым исходным кодом, зачем мне требовать VS 2008 Pro или VS 2005 Team Suite?

MSBuild vs NAnt немного отличается, так как MSBuild связан либо с платформой, либо с SDK (сейчас я не могу вспомнить, какой именно), но я думаю, что NAnt - более приятная среда для работы. MSBuild явно лучше для этого необработанный бит «построить решение» - но вы можете вызвать его из NAnt.