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

Ответ 1

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

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

Ответ 2

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

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

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

Ответ 3

Мне здесь любопытно. Я не понимаю, что люди начинают сравнивать все инструменты Open Source, доступные с MSTest, и начинают избивать его. Комментируя, насколько это громоздко, как unintiuitve и т.д. ИМХО, это потому, что оно принципиально отличается от фреймов xUnit. Он оптимизирован для параллельного выполнения.

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

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

Ответ 4

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

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

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

Ответ 5

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

Ответ 6

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

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

Ответ 7

• MSTest имеет "высокое трение": получение построить script с помощью NAant и MbUnit по сравнению с MStest и MSBuild. нет Сравнение.
• MSTest - Медленный MbUnit и NUnit быстрее работают в моем эксперименте (галли может помочь здесь)
• MStest добавляет куча вещей, которые мне не нужны проводные файлы конфигурации и т.д.
• MSTest не имеет набора фетауров других систем тестирования ОС. проверьте xUnit и MbUnit

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

Ответ 8

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

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

Ответ 9

Чтобы ответить на необоснованный вопрос, мой ответ будет "возможно, NUnit просто остается на вашем лице".

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

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

Ответ 10

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

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

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

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

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

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

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