Есть ли разница между NUnit, MSTest и т. Д.

Question

Есть ли какая-нибудь разница между NUnit, MSTest и т. Д.?

Например, может ли кто-нибудь из них определить, какой код изменился с момента последней сборки, и запустить только затронутые модульные тесты?

Имеет ли кто-нибудь из них тесную интеграцию в настройку / откат базы данных для тестов в стиле интеграции?

Позволяет ли какой-либо из них создавать сценарии TCP-портов или веб-служб для проверки уровня связи?

Answer 1

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

Что касается среды модульного тестирования, все они довольно сопоставимы друг с другом, хотя MSTest является самым молодым (я полагаю). Насколько я знаю, ни один из них вообще не имеет какой-либо неявной (встроенной) интеграции с базами данных, хотя все они поддерживают некоторое понятие настройки и разборки для тестовых классов и методов.

Любой из них предоставит возможность вызывать веб-сервисы и т. Д., Но для сценариев, таких как порты TCP, лучше всего оставить их изолированным или поддельным средам, а не модульным средам тестирования.

Answer 2

Вы можете использовать ant, чтобы запускать только те тесты для кода, который был изменен в последний раз, но это противоречит цели модульных тестов, так как вы могли сломать что-то, чего нет в файле, который вы изменили, поэтому все тесты должен быть запущен.

Вы можете разрабатывать тесты для проверки слоев базы данных или веб-сервиса, объем ваших действий зависит от ваших собственных возможностей.

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

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

MS имеет инфраструктуру модульных тестов базы данных, которая использует TSQL, но она не выполняет автоматического отката в конце теста, но тесты по сценарию.

Answer 3

Определение того, какой код изменился с момента последней сборки, и запуск только уязвимых модульных тестов - это часть того, что серверы Continuous Integration (CI) могут сделать для вас. Джеймс Блэк совершенно прав, что вы хотите запускать соответствующий набор тестов при внесении изменений, а не только один тест или один прибор. Однако у вас может быть проект совместно используемой библиотеки с набором тестов и проект зависимого приложения с собственным набором тестов. Изменения в коде приложения не повлияют на код библиотеки, поэтому вы можете настроить сборку CI для запуска всех тестов, если код библиотеки изменяется, но только тесты приложения, если код приложения изменяется. (Возможно, вы все еще захотите делать ночные сборки.) Это также зависит от вашей ревизии / системы контроля версий; это может быть невозможно в зависимости от комбинации управления источником и программного обеспечения CI.

Мэтью Шарли также прав в том, что зависимости лучше всего обрабатываются средами изоляции / пересмешивания для целей модульных тестов. И NUnit, и MSTest (а также большинство других xUnit платформ) также можно использовать для полных интеграционных тестов (которые используют фактические зависимости, такие как вызов веб-служб).

Для очень предвзятого взгляда на NUnit против MSTest см. MSBuild, NAnt, NUnit, MSTest и разочарование . Строгое сравнение (несколько смещенное в другом направлении) см. Сравнение MSTest и Nunit Frameworks .

С личной точки зрения (чистое мнение) ключевые функции, которые мне нужны, были доступны в NUnit, поэтому я не видел причин для оценки MSTest. Visual Studio Team System имеет очень тесную интеграцию с MSTest (я видел хорошую демонстрацию, которая визуально демонстрирует покрытие кода); если бы моя компания использовала эту (очень дорогую) версию VS, возможно, стоит рассмотреть MSTest. Одним из ключевых вопросов было бы, если бы мы могли заставить его работать с нашим CI-сервером.