Тесты регрессионных компонентов с огурцом. Есть ли какая-либо граница для слоев, которые необходимо протестировать?

64
8

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

Это приложение имеет множество разных типов конечных точек: конечные точки отдыха, которые должны быть вызваны и вызывать, хранимые процедуры Oracle и темы и очереди JMS. Он развернут в военном файле на сервере Tomcat, а фабрика подключений к брокеру и источник данных в базу данных настроены на сервере и извлекаются с использованием JNDI.

Моя первая идея состояла в том, чтобы загрузить все приложение внутри встроенного Jetty, указав на настоящий web.xml, чтобы все было загружено, поскольку оно будет загружено из рабочей среды, а затем издевается над фабрикой соединений и источником данных. Таким образом, вся логика подключения к инфраструктуре, в которой развертывается приложение, будет протестирована. Думая о гексагональной архитектуре, это кажется слишком большим усилием, имея в виду, что это только порты, логика которых должна состоять только в преобразовании полученных данных в данные приложения. Разве это не нужно тестировать?

Моя следующая идея заключалась в том, чтобы просто издеваться над хранимыми процедурами и загружать Spring XML в мой тест без какого-либо веб-сервера, что облегчает издевательство над классами. Для этого я бы использовал библиотеки Spring MockMvc для остальных конечных точек и Mockrunner для JMS. Но опять же, этот подход все равно будет проверять некоторые адаптеры и усложнять тест, поскольку результатом тестов будут XML и JSON. Преобразования, выполненные в этом приложении, довольно тяжелые, когда один и тот же тип сообщения может содержать разные версии класса (каждое сообщение может содержать много сложного объекта, реализующего несколько интерфейсов).

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

Правильно ли этот подход? Могу ли я оставить что-то, не проверив этого? Или это все еще слишком много, и я должен просто доверять модульным тестам?

Благодарю.

спросил(а) 2021-01-25T17:37:50+03:00 6 месяцев назад
1
Решение
64

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

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

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

    Я бы ожидал, что среда приемочного тестирования будет включать сервер Tomcat с тестовыми версиями всех сервисов, существующих в вашей продукции Tomcat, и базу данных со схемой, хранимой процедурой и т.д., Идентичные производственным (но не производственным данным). Управлять внешними зависимостями, которыми вы не владеете, путем укусов и издевательств, используя библиотеку записи/воспроизведения, такую как Betamax и/или путем реализации тестовых версий из них самостоятельно. Приемочные тесты должны быть свободны делать что-либо с данными, и им не нужно беспокоиться о доступности услуг, которыми вы не владеете.

    Напиши достаточно приемочных тестов, чтобы описать основные варианты использования приложения и проверить все важные взаимодействия между частями приложения (обе подсистемы и классы). То есть, используйте приемочные тесты в качестве интеграционных тестов. Я считаю, что между целями принятия и интеграционными испытаниями очень мало конфликтов. Не записывайте больше приемочных тестов, чем требуется для спецификации и интеграции, однако, поскольку они относительно медленны.

    Unit-test каждый класс, который делает что-то интересное, оставляя только те классы, которые полностью протестированы вашими приемочными испытаниями. Поскольку вы уже тестируете интеграцию, ваши модульные тесты могут быть истинными модульными тестами, которые затухают или издеваются над их зависимостями. (Хотя нет ничего плохого в том, чтобы позволить тестируемому модулю использовать реальные зависимости, которые достаточно просты, чтобы не вызывать проблем в модульных тестах).

Измерьте охват кода, чтобы убедиться, что комбинация приемочных и модульных тестов проверяет весь ваш код.

ответил(а) 2021-01-25T17:37:50+03:00 6 месяцев назад
Ваш ответ
Введите минимум 50 символов
Чтобы , пожалуйста,
Выберите тему жалобы:

Другая проблема