пятница, 20 апреля 2018 г.

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

У нас есть обратный поток в 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

Комментариев нет:

Отправить комментарий