AnyStub, библиотека заглушек соединений в Java

[G1yyK]

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

А чем это лучше MokMvc?

[feech1]

Все правильно. Anystub только проксирует и сохраняет за разработчика. Но работает на уровне вызова функций. В результате появляется возможность подменять любой объект.
Непонятен вопрос об управлении файлами — их можно добавить в репозиторий

[nrcmn]

Насколько я понял предыдущий вопрос, ответы сохраняются в файлы, если у вас есть 10 серверов, которые обрабатывают запросы, при попадании запроса, он все равно запрашивает ответ от внешней системы и сохраняет его в файл (или heap), при этом все копится. Если, как я написал, серверов у вас много, а слои фронта (api) и backend(app) разделены, у вас вся информация будет только накапливаться. Вопрос, что с ней делать? Особенно если у вас монолит и 200 методов api.

[ggo]

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

[nrcmn]

Так а что делать если серверов несколько и на каждом разные ответы?

[ggo]

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

[nrcmn]

Есть кластер, в нем 10 апп серверов, запросы на них идут с api-серверов, пришел первый запрос, попал на app-1, получил ответ от внешней системы 404, вернул его api, пришел такой же запрос, попал на app-5, который от внешней системы получил 200 и тело ответа, все это закэшировалось, теперь все такие запросы будут получать либо 200, либо 404, в зависимости от того, на какие апп-серверы попадут. Что с этим делать?

[feech1]

В статье рассказывается о возможности работы с http и sql источниками данных. В вашем случае в тесте вы проверяете как работает ваш api-сервер с кластером апп-серверов.
Если в вашем апп-кластере нет loadbalancer и api-сервер сам балансирует запросы, то каждый запрос имеет уникальное поле host, значит запросы к app-1 и app-5 будут различны и для каждого будет своя запись со своим ответом
Если у кластера есть балансер, значит вероятно api-сервер будет формировать одинаковый запрос несколько раз ожидая другой ответ. для этого предназначен режим rmTrack

[feech1]

Мы говорим о конкретном тесте кейсе? Тогда было бы правильным описать сценарий теста.
Независимо от количества серверов, перед вызовом внешней системы, может осуществлятся поиск запроса в файле, который соответствует текущему тесту.
Обычно сценарии тестов конечны — значит копить необходимо конечное количество запросов.
С созданными файлами надо обходится так же как со всеми стабами — хранить пока они представляют ценность.
Согласен, что одним тестом покрыть api из 200 методов непросто. В статье говорится о создании одного контекста приложения для всех тестов. Наверное будет разумно одним тестом покрывать один use-case пользователя, возможно, он будет задействовать несколько api вызовов.

[nrcmn]

Понятно, это все для функциональных тестов, для нагрузочного тестирования это не подходит.

[feech1]

Нагрузочное тестирование заглушек. Извините, не хватает кармы поставить вам +1

[nrcmn]

:) энтерпрайз он такой

[cepreu4habr]

Очень похоже на vcrpy для Python. Спасибо вам, давно ждал чего-то подобного для Java. Очень не хватало после перехода с Python.
Соответственно вопрос, насколько AnyStub догоняет vcrpy по возможностям? Есть ли там возможность регистрировать кастомные матчеры для запросов (пригождается, если какой-нибудь хидер при каждом запросе случайно генерируемый, так что хотелось бы его игнорировать при матчинге)? Можно ли фильтровать данные, чтобы исключить секретную информацию (логины, пароли всякие)? Если нет, то планируется ли добавлять?

[feech1]

да, оригинальный ruby vcr был вдохновением, но по факту anyStub довольно сильно отличается. В частности, тут уже есть sql.
Про текущую реализацию http — пока я не нашел обоснования для «мачеров». Сейчас есть возможность добавить тело запроса в заглушку или полагаться на детерминированность тестируемой системы (режим rmTrack). Приглашаю в гиттер или issues для обсуждения.
В планах: раширить список «внешних» систем — в основном это датасторы: mongoDB, cassandra, S3, DynamoBD, GemFire