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

Question

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

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

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

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

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

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

Спасибо.

Answer 1

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

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

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

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

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

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

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