Какой самый простой способ перехватить http-звонки из junit?

Question

У нас есть несколько тестов, которые мы запускаем из сценария оболочки. Они звонят в систему A, которая, в свою очередь, вызывает систему B. Поэтому мы имеем 3 отдельных JVM. Эти тесты полностью автоматизированы и выполняются без какого-либо вмешательства человека в систему дженкинсов.

Как часть моего теста, я хочу перехватить вызовы от A до B и проверить различные вещи о содержании. Звонок по-прежнему должен доходить до B, и ответ B должен быть возвращен без изменения к A.

Система A имеет конфигурацию, чтобы указать, где находится B. Все они работают на моей локальной машине, поэтому очевидным вариантом является запуск HTTP-сервера (возможно, причала) из теста, настройка A для разговора с моим временным сервером, а затем, когда я запустил свой тест, сервер увидит весь трафик отправляется с A на B. Затем ему необходимо передать эти запросы в B, получить ответ и вернуть ответ на A. Затем блок-тест должен видеть содержимое каждого запроса как String и выполнять некоторые проверки на нем ,

Я сделал что-то подобное в прошлом, используя причал. Мое предыдущее решение для заглушки делало что-то очень похожее: вместо того, чтобы проксировать вызовы в другую систему, он просто проверял запрос и возвращал фиктивный ответ. Мы ограничены использованием причала 6.1 - использование другой версии было бы неплохо, но PITA.

Я думаю, что пристань может быть лучшим решением. Я мог бы сделать это очень просто, расширив AbstractHandler, а затем создав новый http-вызов в систему B. Но это было бы немного грязно. Есть простой, стандартный способ сделать это?

Answer 1

Простейший способ - нет.

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

Во-вторых, что вы на самом деле надеетесь получить, сделав это? Как это улучшит надежность или качество приложения A? Весьма вероятно, что он не будет, и добавленная сложность в попытке сохранить настройки и дополнительные утверждения на самом деле собираются сделать все less ремонтопригодным.

Так вот что я хотел бы сделать:

1. Написать серию модульных тестов на отдельные биты логики внутри приложений A и B. Они будут проверять логику в изоляции. (Я бы порекомендовал вам выполнить единичные тесты сначала и по отдельности, а затем, когда аппаратные тесты терпят неудачу, ваша сборка может выйти из строя быстрее, прежде чем выполнять интеграционные и функциональные тесты. Интеграция и функциональные тесты будут медленнее и громоздки, поэтому это уведомляет вас о проблемы более быстрые. До вас в этот момент.)
2. Напишите серию интеграционных или функциональных тестов, которые проверяют, что приложение B дает правильный вывод с учетом конкретного ввода.
3. Напишите серию интеграционных или функциональных тестов на входе и выходе A. При написании их просто позвоните в реальный B и предположите, что B работает по назначению.Если это не так, ваши тесты на B-приложения подберут его, и у вас появятся дополнительные сбои в тестах приложения A, которые вы можете игнорировать до тех пор, пока не будет зафиксировано значение B.

Вам не нужно издеваться над всем. Попытка сделать это вызовет у вас больше проблем, чем сэкономит. Чрезмерно сложные тесты будут чистыми убытками.