Как упростить TDD с MSTest / VS2008
Я не думаю, что вы можете, Java использует стирание стилей при компиляции, чтобы ваш код был совместим с приложениями и библиотеками, которые были созданы с предварительными генериками.
Из Oracle Docs:
Тип Erasure
На язык Java были введены обобщения для обеспечения более жестких проверок типа во время компиляции и поддержки общего программирования. Для реализации обобщений компилятор Java применяет стирание типа к:
Замените все параметры типа в родовых типах своими границами или объектом, если параметры типа неограничены. Таким образом, полученный байт-код содержит только обычные классы, интерфейсы и методы. При необходимости вставьте тип приведения, чтобы сохранить безопасность типа. Создание мостовых методов для сохранения полиморфизма в расширенных общих типах. Стирание стилей гарантирует, что для параметризованных типов не создаются новые классы; следовательно, дженерики не накладывают на себя лишний промежуток времени.
blockquote>http://docs.oracle.com/javase/tutorial/java/generics/erasure.html
10 ответов
MSTest, конечно, не так эффективен или расширяем как некоторые платформы с открытым исходным кодом, но это осуществимо. Так как вопрос спрашивает о создании жизни, легче с MSTest а не об альтернативах, здесь является моими подсказками MSTest.
- Ярлыки . Как сказанный Haacked, займите несколько секунд для изучения ярлыков.
- Текущий Контекст . Так как MSTest является настолько медленными, запущенными тестами только в текущем контексте, когда Вы можете. ( CTRL + R , CTRL + T ). Если Ваш курсор будет в методе тестирования, то это только выполнит метод. Если Ваш курсор вне метода, но в тестовом классе, это только запустит тест. И с пространством имен, и т.д. и т.д.
- Эффективные тесты и организация . Это - медленная собака. Сделайте вещи настолько лучше всего, как Вы можете путем записи эффективных тестов. Переместите медленные тесты в другие тестовые классы или проекты, таким образом, можно запускать быстрые тесты более часто.
- Тестирование с WCF. Если Вы - услуги тестирования, несомненно, ОТЛАДЯТ тесты, а не ЗАПУСТЯТ тесты, таким образом, Visual Studio может разжечь веб-серверы разработки ASP.NET. После того, как они произошли, затем можно вернуться к ВЫПОЛНЕННОМУ, но может быть легче просто всегда ОТЛАДКА, таким образом, Вы не должны думать об этом.
- Файлы конфигурации . Отредактируйте свою конфигурацию тестового прогона для перемещения .config файлов в папку выполнения теста.
- Интеграция с Источником, Безопасным . Необходимо знать, что MSTest ненавидит SourceSafe, и чувство взаимно. Поскольку MSTest хочет подвергнуть тестовые файлы управлению исходным кодом и добавить их к решению, это должно проверить решение каждый раз, когда Вы запускаете тесты. Таким образом, SourceSafe должен работать в режиме мультиконтроля, чтобы не уничтожать Ваших поддерживающих разработчиков.
- Игнорируют пух С MSTest, Вы получаете дюжину различных окон и представлений. Тестовые прогоны, Тестовое Представление, Тестовые Списки... они все меньше полезны. Палка с Результатами испытаний и Вы будете намного более счастливыми.
- Палка с "Модульными тестами" . Когда Вы добавляете новый тест, можно добавить заказанный тест, модульный тест, или пробежать мастер. Палка только с простыми модульными тестами.
Если у Вас нет выбора, кроме как использовать MSTest, изучать сочетания клавиш. Они сделают Вашу жизнь немного легче.
Тест в Текущем Контексте: CTRL + R , T
Все Тесты в Решении: CTRL + R , Отладка
Тесты в Текущем Контексте: CTRL + R , CTRL + Отладка T
Все Тесты в Решении: CTRL + R , CTRL +
У моего коллеги Mike Hadlow есть довольно хорошая сводка почему мы совершенно не желающий MSTest здесь .
Им управляют для удаления его из его проекта, но я в настоящее время работаю над большим проектом с большим количеством политики, включенной, таким образом, мы все еще используем его.
результат его - то, что, кто бы ни реализовал MSTest, не понимает TDD. Я сожалею, что походил на убийцу M$ - я действительно нет. Но я раздражаюсь, что я должен выносить очень плохой инструмент.
Мне любопытно здесь. То, что я не понимаю, - то, что люди начинают сравнивать все инструменты Open Source, доступные с MSTest, и начинают колотить его. Комментарий, насколько громоздкий это, как unintiuitve и т.д., по моему скромному мнению, это - потому что это существенно отличается от xUnit платформ. Это оптимизировано для параллельного выполнения.
Даже причуда наличия статического ClassInitialze и Очистки и наличия уникального TestContext для каждого из тестов все из-за следующего поколения - по крайней мере, для программистов бизнеса Windows на языках MS - параллельные понятия программирования.
у меня была неудача работы в проекте с десятками тысяч модульных тестов. Они раньше занимали фактически большую часть времени изготовления! С MSTest мы сокращаем это к очень managable временным шкалам.
Я не видел серьезных проблем с MSTest. О чем, а именно, Вы говорите? Мы, на самом деле, переезжаем от NUnit до MSTest. Я не знаю наши причины этого, все же.
Существует много файлов конфигурации с mstest, делая это менее способствующим.
Другая причина я выбрал mbunit, функция "отката" mbunit. Это позволяет Вам откатывать все вещи базы данных, сделанные в этом тесте, таким образом, можно на самом деле сделать полные тесты канала и не волноваться о водоеме, испорченном после теста.
Также отсутствие средств RowTest в mstest.
я предлагаю просто выполнить mbunit как зависимость в процессе сборки, ее достаточно легкое, чтобы просто пустить в ход его с Вашим мусорным ведром и ссылкой, никакая требуемая установка.
- MSTest имеет "высокое трение": Получение сценария сборки с NAant и MbUnit по сравнению с MStest и MSBuild. Никакое Сравнение.
- MSTest является Медленный MbUnit, и NUnit находятся в моем experince быстрее (Галлио может помочь здесь)
- , MStest добавляет набор материала, в котором я не нуждаюсь как проводные файлы конфигурации и т.д.
- , MSTest не имеет fetaure набора других сред тестирования ОС. проверьте xUnit и MbUnit
Это просто слишком трудно для использования и существует много более оптимальных вариантов.
как уже упоминалось, вам нужно установить полную IDE, чтобы использовать MSTest на другом компьютере, что немного дерьмо. Я полагаю, это потому, что они хотят убедиться, что модульные тесты работают только на визуальных студиях более высокого уровня, и вы сможете запускать их любым другим способом.
ALso, MSTest довольно медленный, это потому, что между каждым тестом он перестраивает весь контекст для каждого теста, это дает уверенность в том, что предыдущий тест - не пройден или иным образом не влияет на текущий тест, но замедляет работу. однако вы можете использовать флаг / noisolation, который будет запускать все тесты внутри процесса MSTest - что быстрее. Для ускорения в IDE: В VS Ide вы можете перейти к Tools-Options, затем выберите Test Tools. Выберите подпункт «Выполнение теста» и в диалоговом окне справа убедитесь, что установлен флажок «Поддерживать работу механизма выполнения теста между тестовыми прогонами».
Для ответа на нерезкий вопрос мой ответ был бы, "вероятно, NUnit просто остается вне поверхности".
Правовая оговорка : у меня нет фактического опыта с версией MS xUnit, однако я слышу, что проблемы как 'Вы должны установить гигантскую идею только для запущения тестов на отдельной машине' - который является полным Нет - Нет. Кроме того, что MS имеет этот способ исказить правильный путь для новичка через некоторый звонок/свист IDE, который работает в противоречии со всей этой мыслью. Как генерация тестов от классов был тот, который я помню приблизительно с одного года назад.. это побеждает смысл делающий пробную поездку - Ваш дизайн, как предполагается, появляется из крошечных шагов RGR: запись теста - делает, она передать - осуществляет рефакторинг. При использовании того инструмента - он отнимает у Вас общее впечатление.
я остановлюсь со своей проповедью.. теперь :)
Я занимался разработкой TDD с использованием NUnit в течение нескольких лет и использую MSTest около 4 месяцев из-за смены ролей.
Я не думаю, что MSTest мешает кому-то выполнять TDD. У вас по-прежнему есть все основные вещи, которые вам нужны для TDD, такие как базовые утверждения и фреймворки для фиксации (я использую Rhino Mocks).
MSTest действительно тесно интегрируется с Visual Studio, лучшим компонентом этой интеграции является встроенный инструмент Code Coverage.
НО Существует ряд веских причин не для использования MSTest. На мой взгляд, два самых больших недостатка:
- Отсутствие опций assert (по сравнению с NUnit)
- Медленное выполнение тестов (медленное по сравнению с NUnit)
Это означает, что для написания asserts требуется больше кода в сочетании с медленный запуск теста означает, что весь процесс медленнее, чем NUnit. Варианты с открытым исходным кодом также имеют гораздо большую поддержку в сообществе.
Если вы используете TFS для CI, вам нужно будет пройти через несколько приемов / уловок, чтобы заставить NUnit опубликовать результаты тестирования. Запуск тестов TFS с MSTest в сравнении очень прост и понятен. Если вы не трогаете TFS, я бы полностью перешел на NUnit, это просто лучше.