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

Question

Я снова и снова читал, что сначала TDD / тестирование сложнее с MSTest, чем с другими платформами тестирования, такими как nUnit, MBUnit и т. Д. что вы предлагаете, когда MSTest является единственным вариантом из-за политики инфраструктуры? В основном меня интересует VS 2008 Team Suite, но я полагаю, что советы по использованию VS 2008 Pro также подойдут, поскольку некоторые функции MSTest теперь включены и в эти версии.

Answer 1

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

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

Answer 2

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

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

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

Answer 3

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

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

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

Answer 4

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

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

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

Answer 5

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

Так же, MSTest довольно медленный, это потому, что между каждым тестом он перестраивает весь контекст для каждого теста, это дает уверенность, что предыдущий тест - провалился или иным образом не влияет на текущий тест, но замедляет работу. однако вы можете использовать флаг / noisolation, который будет запускать все тесты внутри процесса MSTest - что быстрее. Для ускорения в IDE: В VS Ide вы можете перейти к Tools-Options, а затем выбрать Test Tools. Выберите подпункт «Выполнение теста» и в диалоговом окне справа убедитесь, что установлен флажок «Поддерживать работу механизма выполнения теста между тестовыми прогонами».

Answer 6

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

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

Answer 7

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

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

Answer 8

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

Answer 9

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

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

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

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

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

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

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

Answer 10

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

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

Я перестану с моей проповедью .. сейчас :) 1009 *