Как облегчить TDD с MSTest / VS2008

MSTest, конечно, не так эффективна и расширяема, как некоторые из фреймворков с открытым исходным кодом, но она работоспособна. Поскольку вопрос заключается в том, чтобы облегчить жизнь с помощью MSTest, а не об альтернативах, вот мои советы MSTest.

• Ярлыки. Как сказал Хаак, вам потребуется несколько секунд, чтобы выучить короткие пути.
• текущий контекст . Поскольку MSTest работает очень медленно, запускайте тесты только в текущем контексте, когда это возможно. ( CTRL + R , CTRL + T ). Если курсор находится в тестовом методе, то будет выполняться только этот метод. Если курсор находится вне метода, но в тестовом классе, то будет выполняться только тест. И с пространством имен, и т. д.
• Эффективные тесты и организация . Это по-собачьи медленно. Сделайте все как можно лучше, написав эффективные тесты. Переместите медленные тесты в другие тестовые классы или проекты, чтобы вы могли чаще выполнять быстрые тесты.
• Тестирование с помощью WCF . Если вы тестируете службы, обязательно используйте DEBUG тестов, а не RUN тестов, чтобы Visual Studio могла запускать веб-серверы разработки ASP.NET. После того, как они закончатся, вы можете вернуться к RUN, но может быть проще просто всегда DEBUG, чтобы вам не нужно было думать об этом.
• конфигурационный файл . Измените конфигурацию запуска теста, чтобы переместить файлы .config в папку выполнения теста.
• Интеграция с Source Safe . Вы должны знать, что MSTest ненавидит SourceSafe, и это чувство взаимно. Поскольку MSTest хочет поместить тестовые файлы в систему управления версиями и добавить их в решение, он должен проверять решение каждый раз при запуске тестов. Так что SourceSafe должен работать в режиме multi-check-out, чтобы не убивать своих коллег-разработчиков.
• Не обращайте внимания на пух с MSTest, вы получите дюжину различных windows и просмотров. Тестовые Прогоны, Просмотр Тестов, Списки Тестов ... они все less-than-helpful. Придерживайтесь результатов тестов, и вы будете намного счастливее.
• Придерживайтесь "Unit Tests" . При добавлении нового теста можно добавить заказанный тест, модульный тест или запустить его с помощью мастера. Придерживайтесь только простых модульных тестов.

Если у вас нет выбора, кроме как использовать MSTest, изучите сочетания клавиш. Они сделают вашу жизнь немного легче.

Тест в текущем контексте: CTRL + R , T
Все тесты в решении: CTRL + R, A

Отладочные тесты в текущем контексте: CTRL + R , CTRL + T
Отладьте все тесты в решении: CTRL + R , CTRL + A

Мне здесь любопытно. Чего я не понимаю, так это того, что люди начинают сравнивать все доступные инструменты с открытым исходным кодом с MSTest и начинают бить его. Комментируя, насколько он громоздкий, насколько неинтеллектуальный и т. д. IMHO, это потому, что он принципиально отличается от xUnit фреймворков. Он оптимизирован для параллельного выполнения.

Даже Курик, имеющий статические ClassInitialze и очистки и имеющий уникальный TestContext для каждого из тестов все из - за nextgen - по крайней мере для Windows бизнес-программистов на MS языках-параллельных прогарм-концепций.

Я имел несчастье работать в проекте с десятками тысяч модульных тестов. Раньше они занимали практически все время сборки! С MSTest мы сократили это до очень управляемых временных рамок.

У моего коллеги Майка Хэдлоу есть довольно хорошее резюме того, почему мы совершенно ненавидим MSTest здесь .

Ему удалось удалить его из своего проекта, но в настоящее время я работаю над более крупным проектом с большим количеством политиков, поэтому мы все еще используем его.

В результате получается, что тот, кто реализовал MSTest, не понимает TDD. Мне жаль, что я говорю так, как будто я M$ - трепач, но это не так. Но меня раздражает, что мне приходится мириться с очень плохим инструментом.

Я не видел никаких серьезных проблем с MSTest. О чем конкретно вы говорите? На самом деле мы движемся от NUnit к MSTest. Впрочем, я не знаю наших причин для этого.

Есть много конфигурационных файлов с помощью программы MSTest, делая его менее располагающее.
Еще одна причина, по которой я выбрал mbunit, - это функция "rollback" в mbunit. Это позволяет вам откатить все вещи базы данных, сделанные в этом тесте, так что вы можете на самом деле сделать полный цикл тестов и не беспокоиться о том, что пруд будет испорчен после теста.
Также отсутствует RowTest объектов в mstest.

Я предлагаю просто запустить mbunit в качестве зависимости внутри процесса сборки, его достаточно легко просто поместить в вашу корзину и ссылку, не требующую установки.

как уже упоминалось ою нужно установить полный IDE для того, чтобы использовать MSTest на другой машине, что немного дерьмово. Я предполагаю, что это происходит потому, что они хотят убедиться, что модульные тесты работают только на более высоком уровне visual studios, и вы не сможете запустить их любым другим способом.

ALso, MSTest довольно медленно, это происходит потому, что между каждым тестом он перестраивает весь контекст для каждого теста, это делает o0ne уверенным, что предыдущий тест - неудачный или иначе не влияет на текущий тест, но замедляет процесс. однако вы можете использовать флаг /noisolation, который будет выполнять все тесты в рамках процесса MSTest - что быстрее. Чтобы ускорить работу в IDE:в VS ide вы можете перейти к инструментам-параметры, а затем выбрать инструменты тестирования. Выберите подпункт под названием выполнение теста и в dialouge справа убедитесь, что установлен флажок "поддерживать работу механизма выполнения тестов между тестовыми запусками".

• MSTest имеет "высокое трение": получение сценарий сборки с NAant и MbUnit по сравнению с MStest и MSBuild. Нет Сравнение.
• MSTest медленно MbUnit и NUnit находятся в моем опыте быстрее (здесь может помочь Галлион)
• MStest добавляет a куча вещей которые мне не нужны например проводные конфигурационные файлы и т. д.
• MSTest не имеет набора fetaure других тестовых фреймворков OS. проверьте xUnit и MbUnit

Это просто слишком трудно использовать, и есть много лучших вариантов.

Я занимался разработкой TDD с использованием NUnit в течение нескольких лет и использовал MSTest уже около 4 месяцев из-за изменения роли.

Я не думаю, что MSTest останавливает кого-то от выполнения TDD. У вас все еще есть все основные вещи, которые вам нужны для TDD, такие как основные утверждения и насмешливые фреймворки (я использую Rhino Mocks).

MSTest тесно интегрируется с Visual Studio, лучшим компонентом этой интеграции является встроенный инструмент покрытия кода.

НО Существует ряд убедительных причин не использовать MSTest. Два самых больших отключения на мой взгляд являются:

1. Отсутствие вариантов assert (по сравнению с NUnit)
2. Вялый бегун теста (медленный по сравнению с NUnit)

Это означает, что написание asserts занимает больше кода в сочетании с медленным запуском теста означает, что весь процесс идет медленнее, чем NUnit. Варианты с открытым исходным кодом также имеют гораздо большую поддержку в сообществе.

Если вы используете TFS для CI, то вам нужно будет перепрыгнуть через несколько обручей/хаков, чтобы получить NUnit для публикации результатов теста. Запуск тестов на TFS с MSTest в сравнении очень прост и прямолинейен. Если вы не трогаете TFS, то я бы пошел NUnit до конца, это просто приятнее.

Чтобы ответить на неострый вопрос, мой ответ будет следующим: "probably NUnit just stays out of your face."

Отказ от ответственности: у меня нет реального опыта работы с MS версией xUnit, однако я слышу такие проблемы, как "вам нужно установить гигантскую идею, чтобы просто запустить свои тесты на отдельной машине" - что является полным No-No. Кроме того, MS имеет такой способ искривления правильного пути для новичка через какой-то колокол/свисток IDE, который противоречит всей идее. Как будто генерирование тестов из классов было одним из тех, что я помню примерно год назад.. это разрушает весь смысл тест-драйва - ваш дизайн должен появиться из крошечных шагов RGR: написание теста-сделайте его проходным-рефактор. Если вы используете этот инструмент - он лишает вас всего опыта.

Я остановлюсь на своей проповеди.. сейчас :)