dimanche 31 mars 2019

Design pattern for Cucumber assertions partially matching messages

I am trying to write a component testing framework for an application. This application can send messages through JMS/Websockets (the transport isn't important). I'm using cucumber to define my BDD steps.

After an action has been performed a number of events will have been sent to the component testing server for matching against the expected list.

I'm looking for a design pattern/approach that will give me the flexibility to write different named fields in the data table for the same message type without having the code behind them being bloated by boilerplate for each specific field.

Example, given a message with the following definition:

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

I want to be able to write different assertions:

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|

A couple of ways I have thought of for performing this type of validation:

1) Loop through the received messages, filter out all order messages. Then for each named field define a lookup function on that given an order message will return the value for that field. Check equality for all fields on each received message.

This approach will leave a lot of boiler plate code because you have to define specific lookup functions for each value in the message (these messages can have 100 fields)

2) Create an Order POJO. Parse the received messages into an Order POJO. Also parse the fields defined in the assertion into the POJO. In the equals method do something like 'if field is set from assertion, then include it in equality check, else exclude it'.

This feels better but might have problems when message has a list type. Ie should the list be null, or empty list? Can we have lists of ignored values with certain size?

There must be documentation/design patterns around this but I can't find any good examples. Any pointers in the right direction would be appreciated

Aucun commentaire:

Enregistrer un commentaire