да, оригинальный ruby vcr был вдохновением, но по факту anyStub довольно сильно отличается. В частности, тут уже есть sql.
Про текущую реализацию http — пока я не нашел обоснования для «мачеров». Сейчас есть возможность добавить тело запроса в заглушку или полагаться на детерминированность тестируемой системы (режим rmTrack). Приглашаю в гиттер или issues для обсуждения.
В планах: раширить список «внешних» систем — в основном это датасторы: mongoDB, cassandra, S3, DynamoBD, GemFire
В статье рассказывается о возможности работы с http и sql источниками данных. В вашем случае в тесте вы проверяете как работает ваш api-сервер с кластером апп-серверов.
Если в вашем апп-кластере нет loadbalancer и api-сервер сам балансирует запросы, то каждый запрос имеет уникальное поле host, значит запросы к app-1 и app-5 будут различны и для каждого будет своя запись со своим ответом
Если у кластера есть балансер, значит вероятно api-сервер будет формировать одинаковый запрос несколько раз ожидая другой ответ. для этого предназначен режим rmTrack
Мы говорим о конкретном тесте кейсе? Тогда было бы правильным описать сценарий теста.
Независимо от количества серверов, перед вызовом внешней системы, может осуществлятся поиск запроса в файле, который соответствует текущему тесту.
Обычно сценарии тестов конечны — значит копить необходимо конечное количество запросов.
С созданными файлами надо обходится так же как со всеми стабами — хранить пока они представляют ценность.
Согласен, что одним тестом покрыть api из 200 методов непросто. В статье говорится о создании одного контекста приложения для всех тестов. Наверное будет разумно одним тестом покрывать один use-case пользователя, возможно, он будет задействовать несколько api вызовов.
Все правильно. Anystub только проксирует и сохраняет за разработчика. Но работает на уровне вызова функций. В результате появляется возможность подменять любой объект.
Непонятен вопрос об управлении файлами — их можно добавить в репозиторий
Как это напоминает конфигурацию спринг контекста в XML.
Новичок! Не создавай сервисы и реализации в своем "бизнес-коде" (как может показаться из этой статьи).
УчиПонимай шаблоны программирования.Про текущую реализацию http — пока я не нашел обоснования для «мачеров». Сейчас есть возможность добавить тело запроса в заглушку или полагаться на детерминированность тестируемой системы (режим rmTrack). Приглашаю в гиттер или issues для обсуждения.
В планах: раширить список «внешних» систем — в основном это датасторы: mongoDB, cassandra, S3, DynamoBD, GemFire
Если в вашем апп-кластере нет loadbalancer и api-сервер сам балансирует запросы, то каждый запрос имеет уникальное поле host, значит запросы к app-1 и app-5 будут различны и для каждого будет своя запись со своим ответом
Если у кластера есть балансер, значит вероятно api-сервер будет формировать одинаковый запрос несколько раз ожидая другой ответ. для этого предназначен режим rmTrack
Независимо от количества серверов, перед вызовом внешней системы, может осуществлятся поиск запроса в файле, который соответствует текущему тесту.
Обычно сценарии тестов конечны — значит копить необходимо конечное количество запросов.
С созданными файлами надо обходится так же как со всеми стабами — хранить пока они представляют ценность.
Согласен, что одним тестом покрыть api из 200 методов непросто. В статье говорится о создании одного контекста приложения для всех тестов. Наверное будет разумно одним тестом покрывать один use-case пользователя, возможно, он будет задействовать несколько api вызовов.
Все правильно. Anystub только проксирует и сохраняет за разработчика. Но работает на уровне вызова функций. В результате появляется возможность подменять любой объект.
Непонятен вопрос об управлении файлами — их можно добавить в репозиторий