Блог

Я пытаюсь написать платформу тестирования компонентов для приложения. Это приложение может отправлять сообщения через JMS / Websockets (транспорт не важен). Я использую cucumber для определения моих шагов BDD.

После выполнения действия на сервер тестирования компонентов будет отправлен ряд событий для сопоставления с ожидаемым списком.

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

Например, дано сообщение со следующим определением:

 Order {
  String orderId;
  int size;
  int amount;
  String name;
}
  

Я хочу иметь возможность писать разные утверждения:

 Then I should have received following orders:
|orderId|size|amount|
|order1 | 10 | 50   |
|order2 | 5  | 10   |
  

 Then I should have received following orders:
|orderId|name |
|order1 |ted  |
|order2 |steve|
  

Я придумал пару способов для выполнения этого типа проверки:

1) Просмотрите полученные сообщения, отфильтруйте все сообщения заказа. Затем для каждого именованного поля определите функцию поиска, для которой заданное сообщение order вернет значение для этого поля. Проверьте равенство для всех полей в каждом полученном сообщении.

Этот подход оставит много кода на табличной части, потому что вам нужно определить конкретные функции поиска для каждого значения в сообщении (эти сообщения могут содержать 100 полей)

2) Создайте POJO для заказа. Проанализируйте полученные сообщения в POJO порядка. Также проанализируйте поля, определенные в утверждении, в POJO. В методе equals сделайте что-то вроде ‘если поле задано из утверждения, затем включите его в проверку на равенство, иначе исключите его’.

Это выглядит лучше, но может вызвать проблемы, когда сообщение имеет тип списка. Т. е. должен ли список быть нулевым или пустым списком? Можем ли мы иметь списки игнорируемых значений определенного размера?

Вокруг этого должна быть документация / шаблоны проектирования, но я не могу найти хороших примеров. Любые указатели в правильном направлении были бы оценены