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

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

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

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

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


msbuild nunit mstest nant
person Community    schedule 21.10.2008    source источник

Ответы (2)


arrow_upward
5
arrow_downward

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

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

person Mendelt    schedule 21.10.2008

arrow_upward
4
arrow_downward

На мой взгляд, 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 и NAnt немного отличаются, поскольку MSBuild связан либо с фреймворком, либо с SDK (сейчас я не могу вспомнить, какой именно) - но я думаю, что NAnt - более приятная среда для работы. MSBuild явно лучше подходит для необработанных данных ». построить "решение", но вы можете вызвать его из NAnt.

person Jon Skeet    schedule 21.10.2008