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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Чтобы ответить на непонятный вопрос, я бы ответил: «Вероятно, NUnit просто держится подальше от вас».

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

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

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

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

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

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

1. Отсутствие опций assert (по сравнению с NUnit)
2. Медлительный тестовый запуск (медленный по сравнению с NUnit)

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

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