Как создать приемочные тесты для асинхронных микро сервисов

Question

Если у меня есть Microservice, который должен создать пользователя, но поскольку создание пользователя является сложным, он использует очередь, и пользователь фактически создается потребителем, конечная точка только принимает запрос и возвращает ok или сбой.

Как мне создать приемочный тест для этого критерия принятия:
Дано: Пользователь, который хочет зарегистрироваться
Когда: api запрашивается для создания пользователя
Затем: создайте пользователя И установите хост-среду_идентификатора для нового пользователя

Для этого мне придется подождать, пока среда фактически настроится, что занимает до 30 секунд.И если я внедряю режим сна в свой тест, тогда я нажимаю на анти-паттерн , подождите и увидите , как правильно протестировать его, не отказавшись от лучших практик?

Answer 1

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

Этот «опрос» может принимать различные формы, такие как:

a) запрос ожидаемого обновления базы данных (возможно, значение в таблице обновляется при создании пользователя)

b) проверяет связь с зависимой службой, пока вы не получите соответствующий «сигнал»вы ожидаете указать создание пользователя.Например, возможно, запрос GET к другой службе (или другой конечной точке той же службы) возвращает статус «создан» для данного пользователя, что означает, что пользователь был создан.

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

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

Некоторые другиев этом сценарии используются следующие предположения:

a) достаточные нефункциональные характеристики тестируемой системы, в которых ограничение нефункциональной производительности тестируемой системы будет ограничением.

b) aотсутствие ресурсных ограничений, так как ресурсы потребляются довольно сильно во время «опроса», так как ресурсы потребляются довольно сильно в течение «опроса».(подумайте о динамическом сгибании ресурсов Azure, который может быть дорогостоящим со временем).

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

Answer 2

Создайте службу запросов, которая с учетом пользовательских атрибутов (идентификатор или имя и т. Д.) Будет возвращать статус пользователя.

По критериям приемки будет 2 части

1. create-user услуга возвращается 200
2. get-status сервис возвращает 200 (вы можете вызвать его в цикле в своем тесте).

Эта услуга будет полезна в долгосрочной перспективе по различным причинам

1. Проверьте, сколько времени занимает завершение асинхронного процесса.
2. В любое время вы можете получить статус любого пользователя, в том числе проверить, действительно ли пользователь удален / деактивирован и т. Д.
3. Вы можете смоделировать эту услугу в результате комплексного интегрированного тестирования.

Answer 3

наиболее правильным может быть немедленный возврат ответа, скажем, «процесс установки запущен» (с идентификатором процесса установки), а затем другой метод API, который будет «получать статус установки» (для этого идентификатора процесса установки) -и затем продолжить, когда «установка завершена».

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

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

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