NUnit против MSTest - непостоянный опыт новичка TDD с обоими - PullRequest
2 голосов
/ 03 марта 2010

Здесь, на SO, есть множество вопросов, касающихся NUnit vs. MSTest, и я прочитал довольно много из них. Я думаю, что мой вопрос здесь немного отличается, чтобы опубликовать отдельно.

Когда я начал использовать C #, я даже не задумывался о том, чтобы посмотреть на MSTest, потому что я так привык к тому, что он не был доступен, когда я ранее использовал C ++. Я в основном забыл все об этом. :) Так что я начал с NUnit, и мне понравилось. Тесты были очень просты в настройке, и тестирование не было слишком болезненным - просто запустите IDE и запустите тесты!

Как отмечают многие, NUnit часто обновляется, а MSTest обновляется только так часто, как IDE. Это не обязательно проблема, если вам не нужно быть на переднем крае TDD (а я нет), но проблема, с которой я сталкивался при частых обновлениях, заключается в поддержании всех систем в актуальном состоянии. Я использую около четырех или пяти разных компьютеров в день, и хотя обновление всех из них не так уж и сложно, я надеялся, что мой код будет правильно компилироваться в системах с более старой версией NUnit. Так как мой проект ссылался на папку установки NUnit, при обновлении инфраструктуры все компьютеры с более старой установленной платформой больше не могли компилировать мой проект. Я пытался бороться с этой проблемой, создав в SVN общую папку, в которой были только библиотеки NUnit, но даже тогда она как-то жаловалась на номер версии двоичного файла. Есть ли способ обойти эту проблему? Это то, что заставило меня перестать использовать в первый раз.

Тогда однажды я вспомнил MSTest и решил попробовать. Мне понравилось, что он был интегрирован в IDE. CTRL-R, CTRL-A, все тесты запускаются. Как просто! Но затем я увидел, что типы тестов, доступных в MSTest, были довольно ограничены. Я не знал, сколько мне на самом деле нужно, но решил, что должен вернуться в NUnit, и я это сделал.

Примерно сейчас я начинал отлаживать модульные тесты, и единственный способ понять, как это сделать в NUnit, - это установить NUnit в качестве запускаемого приложения, а затем установить точки останова в моих тестах. Затем в графическом интерфейсе NUnit я запускал тесты, чтобы достичь точек останова. Это была полная PITA. Затем я снова посмотрел на графический интерфейс MSTest и увидел, что могу просто нажать Отладка там, и он выполнит мои тесты! ВОТ ЭТО ДА! Теперь это была убийственная особенность, которая заставила меня вернуться в пользу MSTest.

Прямо сейчас я снова использую MSTest. К сожалению, сегодня я начал задумываться о ежедневных сборках и провел поиск в Tinderbox, который является единственным инструментом, о котором я слышал ранее для такого рода вещей. Это открыло мне глаза на другие инструменты, такие как buildbot и TFS. Таким образом, проблема в том, что я думаю, что MSTest гарантированно заблокирует меня в TFS для автоматических ежедневных сборок, или для непрерывной интеграции, или как бы там ни было модным словом. Моя компания не может позволить себе привязываться к решениям только для MS (кроме VS), поэтому я хочу изучить другие варианты.

Я в полном порядке, чтобы вернуться в NUnit. Я не в восторге от переписывания более 100 юнит-тестов, но так оно и есть. Тем не менее, я бы очень хотел, чтобы кто-то объяснил, как раздавить эти две проблемы, которые вкратце:

  1. как мне настроить NUnit и мой проект, чтобы мне не приходилось постоянно обновлять его в каждой системе для сборки проекта?
  2. как мне упростить отладку модульных тестов? Мой подход был болезненным, потому что мне приходилось постоянно переключаться между NUnit и приложением по умолчанию для тестирования / запуска моего приложения. Я видел пост здесь на SO, в котором упоминалось NUnitIt на codeplex , но у меня нет никакого опыта с ним.

ОБНОВЛЕНИЕ - Я сравниваю вещи в моей виртуальной машине разработки, и до сих пор NUnitit довольно хорош. Его легко установить (одним щелчком мыши), и я просто указываю на то, какие двоичные файлы NUnit находятся в моей внешней папке SVN. Неплохо! Я также вошел в VS -> Инструменты -> Параметры -> Клавиатура и изменил свое отображение для CTRL-R, CTRL-A, чтобы сопоставить с NUnitit.Connect.DebugGUI. Не идеально, так как я не понял, как заставить NUnit автоматически запускать тесты, когда он открыт, но это довольно хорошо. И отладка работает как надо сейчас!

ОБНОВЛЕНИЕ № 2 - Я установил TestDriven.Net и быстро его пробежал. В целом, он мне нравится намного лучше, чем NUnitit, но на данный момент NUnitit выигрывает, потому что он бесплатный, и, поскольку он также работает с NUnit, он позволит мне «обновиться» до TestDriven.Net, когда придет время. Что мне больше всего нравится в TestDriven.Net, так это то, что, когда я дважды щелкаю по неудачному тесту, я сразу перехожу к строке неудачного теста, в то время как NUnit + NUnitit, похоже, не способен на это. Кто-нибудь смог создать эту связь между NUnit GUI и VS IDE?

Ответы [ 3 ]

2 голосов
/ 03 марта 2010

Для упрощения отладки (и запуска тоже) модульных тестов я рекомендую проверить TestDriven.Net . Функция «Test With> Debugger» очень удобна. Персональная версия бесплатна.

2 голосов
/ 03 марта 2010

Многие проекты, над которыми я работал, включали копию определенной версии NUnit (или xUnit.net, как угодно) в папку "lib", "extrernal" или "библиотеки" в их контроле исходного кода, и ссылаются на то, что Место для построения всех своих тестов. Это значительно уменьшает головную боль при «обновлении всех», поскольку вам не нужно устанавливать NUnit или xUnit.net, чтобы использовать его.

Этот подход все еще позволяет вам использовать что-то вроде TestDriven.Net для выполнения тестов, запуска тестов в отладчике и т. Д.

0 голосов
/ 03 марта 2010

Играли ли вы со свойством «Конкретная версия» в справочнике NUnit.framework? Мы оставляем для нас значение true, чтобы тесты, закодированные для данной версии nunit, требовали выполнения этой конкретной версии.

Я не уверен, как он справится, например, если у вас на компьютере было 2.5, а на другой машине было только 2.4 - .NET с радостью связывался бы с версией 2.4 или только с более ранних версий до более поздних версий сборки (например, скомпилированный против 2.4, но доступный 2.5 во время выполнения?)

...