Автоматизация брокеров сообщений
Расскажу на примере Kafka, как и когда это тестировать, так как это самый популярный брокер
Сначала зачем это вообще нужно
Во многих системах сервисы общаются не напрямую, а через очереди сообщений
Один сервис кидает сообщение в топик, другой его забирает и что то делает. И если эта цепочка ломается, пользователь может вообще не увидеть свой заказ или уведомление. Поэтому такие потоки обязательно надо проверять
Как подключаться к Kafka из тестов
Тут не нужно ничего магического
Есть обычная библиотека kafka-clients, через неё ты и подключаешься к брокеру прямо из автотестов. Поднимаешь продюсера или консьюмера, указываешь адрес брокера и нужный топик, и дальше работаешь руками кода
1️⃣Сценарий первый, проверяем консьюмером
Это случай, когда тебя интересует, что система сама что то положила в топик
Ты дёргаешь какое то действие в приложении, например создаёшь заказ через API, а потом своим консьюмером читаешь топик и проверяешь, что туда прилетело нужное сообщение с правильными данными
То есть ты выступаешь читателем и убеждаешься, что система действительно отправила событие, а не просто сделала вид
2️⃣Сценарий второй, отправляем продюсером
А тут наоборот, ты сам кидаешь сообщение в топик
Это нужно, когда ты хочешь проверить, как система реагирует на входящее событие. Ты своим продюсером отправляешь сообщение, а потом смотришь на результат, например что в базе появилась новая запись или сменился статус заказа
Здесь ты как бы имитируешь соседний сервис, который в реальности шлёт эти события
Как понять, какой сценарий выбирать
Всё зависит от того, что ты проверяешь, вход или выход
Если тебя интересует, что система отправляет наружу, ты читаешь консьюмером. Если интересует, как система обрабатывает входящее, ты отправляешь продюсером. По сути ты просто встаёшь с нужной стороны очереди
Пара важных моментов на практике
Не забывай про таймауты при чтении, потому что сообщение прилетает не мгновенно, и тест должен подождать, а не сразу падать
Ещё аккуратнее с тем, откуда читать топик, чтобы не зацепить старые сообщения от прошлых прогонов. И лучше использовать отдельные тестовые топики, чтобы не мешать чужим данным
Тестировать Kafka не страшно, всё сводится к двум ролям
Когда проверяешь, что система отправила событие, ты читаешь консьюмером. Когда проверяешь реакцию на входящее, ты шлёшь продюсером. А подключаешься ко всему этому через обычный kafka-clients, и никакой магии тут нет
Расскажу на примере Kafka, как и когда это тестировать, так как это самый популярный брокер
Сначала зачем это вообще нужно
Во многих системах сервисы общаются не напрямую, а через очереди сообщений
Один сервис кидает сообщение в топик, другой его забирает и что то делает. И если эта цепочка ломается, пользователь может вообще не увидеть свой заказ или уведомление. Поэтому такие потоки обязательно надо проверять
Как подключаться к Kafka из тестов
Тут не нужно ничего магического
Есть обычная библиотека kafka-clients, через неё ты и подключаешься к брокеру прямо из автотестов. Поднимаешь продюсера или консьюмера, указываешь адрес брокера и нужный топик, и дальше работаешь руками кода
1️⃣Сценарий первый, проверяем консьюмером
Это случай, когда тебя интересует, что система сама что то положила в топик
Ты дёргаешь какое то действие в приложении, например создаёшь заказ через API, а потом своим консьюмером читаешь топик и проверяешь, что туда прилетело нужное сообщение с правильными данными
То есть ты выступаешь читателем и убеждаешься, что система действительно отправила событие, а не просто сделала вид
2️⃣Сценарий второй, отправляем продюсером
А тут наоборот, ты сам кидаешь сообщение в топик
Это нужно, когда ты хочешь проверить, как система реагирует на входящее событие. Ты своим продюсером отправляешь сообщение, а потом смотришь на результат, например что в базе появилась новая запись или сменился статус заказа
Здесь ты как бы имитируешь соседний сервис, который в реальности шлёт эти события
Как понять, какой сценарий выбирать
Всё зависит от того, что ты проверяешь, вход или выход
Если тебя интересует, что система отправляет наружу, ты читаешь консьюмером. Если интересует, как система обрабатывает входящее, ты отправляешь продюсером. По сути ты просто встаёшь с нужной стороны очереди
Пара важных моментов на практике
Не забывай про таймауты при чтении, потому что сообщение прилетает не мгновенно, и тест должен подождать, а не сразу падать
Ещё аккуратнее с тем, откуда читать топик, чтобы не зацепить старые сообщения от прошлых прогонов. И лучше использовать отдельные тестовые топики, чтобы не мешать чужим данным
Тестировать Kafka не страшно, всё сводится к двум ролям
Когда проверяешь, что система отправила событие, ты читаешь консьюмером. Когда проверяешь реакцию на входящее, ты шлёшь продюсером. А подключаешься ко всему этому через обычный kafka-clients, и никакой магии тут нет