Как я забыла проверить обрыв соединения в процессе работы

У нас есть обратный поток в JMS, но обычно мы отправляем сообщения в EMS (Tibco). Тут возникла задачка отправлять сообщения сразу в два потока: EMS и RabbitMQ.

Так как на EMS уже все проверено и протестировано, размышляю я, моя задача только в том, чтобы проверить, а работает ли тоже самое для RabbitMQ. И даже учла возможность нерабочей шины! Проверила разные варианты, причем в автотестах:

1. Настройка включена, параметры настроены — все работает.
2. Настройка включена, параметры не настроены — в лог падает ошибка.
3. Настройка выключена, параметры настроены — сообщения НЕ уходят, настройка то выключена.
4. Настройка выключена, параметры не настроены — сообщения не уходят, проверки на корректность параметров нет (ошибки не валятся).

См также:

Применение класса «ноль-не ноль» при подключении к JMS — подробнее о том, почему именно такие тесты.

Все хорошо, все работает. А если настройка выключена или сам рэббит не работает — тоже все хорошо. Отдали Заказчику на тестирование. Они проверяют на своей стороне и приходят с вопросом:

— Хотел уточнить следующий кейс: в штатном режиме работы связки CDI + Rabbit MQ отваливается подключение к RabbitMQ. Иванов Иван подсветил, что в этом случае перестают отрабатывать запросы на изменение данных. Это корректное поведение? Так и запланировано?

Я в дороге была, когда прочитала этот вопрос. Еду, вспоминаю. Проверяла ли я такую ситуацию? 

И тут понимаю, что скорее всего нет, ведь основной упор шел на автотесты. А в автотестах ты задаешь исходное состояние: шина или работает, или нет. И вручную также смотрела: меняла настройки и рестартовала сервер, чтобы они подхватились. Так что сервер при старте  проверял подключение. 

А вот про кейс «сначала все хорошо, а в процессе работы отвалился» забыла. Ай-яй-яй, простейшие классы эквивалентности, «начало-середина-конец»!

Посмотрели, выяснили: данные то в конечном итоге изменяются. Но только после того, как клиент получил ошибку read time out. Потому что сначала система пытается достучаться таки до рэббита, и уже пото-о-о-ом, прождав больше минуты, плюет и сохраняет данные. Но клиент об этом не знает, так как уже получил отлуп (под клиентом понимается система, которая шлет в нашу данные, или Soap Ui, которые ее заменяет при ручном тестировании).

Штатными средствами, кстати, исправить не удалось. Пришлось допиливать клиентскую либу, потому что родная фабрика не позволяет задать connectionTimeout. 

Но я это к чему? Не забывайте тестировать класс «начало-середина-конец». И помните, что он работает не только для длины строки. Это может быть и состояние системы:

• Не работало сразу.
• Сначала работало, а уже в процессе отвалилось.

Или соединение с базой / JMS / SFTP:

• Соединение есть;
• Соединения нет;
• Соединение есть, но отваливается в процессе работы.

Как видите, это совершенно разные кейсы и проверка одного не гарантирует работу другого ツ

См также:

Как подключение RabbitMQ сломало нам отображение версий — еще одна история про подключение RabbitMQ