Как упростить TDD с помощью MSTest/VS2008

https://stackoverflow.com/questions/29557

09-06-2019
|

Вопрос

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

Решение

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

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

Другие советы

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

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

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

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

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

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

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

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

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

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

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

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

MSTest имеет «высокое трение»:Получение сценария сборки с NAANT и MBUNIT по сравнению с MSTest и MSBUILD.Нет сравнения.
MSTest - это медленный Mbunit, а NUNIT быстрее - это быстрее (Gallio может помочь здесь)
MSTest добавляет кучу вещей, которые мне не нужны, как проводные файлы конфигурации и т. Д.
MSTest не имеет набора функций других платформ тестирования ОС.проверьте xUnit и MbUnit

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

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

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

Чтобы ответить на неоплаченный вопрос, мой ответ будет: «Вероятно, NUNIT просто остается вне вашего лица».

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

Я закончу свою проповедь..сейчас :)

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

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

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

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

Отсутствие опций утверждения (по сравнению с NUnit)
Медленный запуск тестов (медленный по сравнению с NUnit)

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

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

Лицензировано под: CC-BY-SA с атрибуция

Не связан с StackOverflow