Cucumber and Distributed Application Testing
Writing distributed applications is complex. Testing distributed application is as complex. Throw in a distributed applications that spans a LAN/WAN with latency implications, and the software engineering/testing complexities become quite painful to model.
Cucumber in my view is nice from the perspective that is allows the tests to be written in pain text, and in a business DSL. Sometime ago whilst writing a distributed application, and trying to code the cucumber tests, I realised that I could benefit from the sequence diagrams (PlantUML) that I had draw to allow me to visualise the message flow between the various interested parties (nodes) in my Proof of Concept (PoC).
My idea was to get Cucumber to include the sequence diagram as part of the “Then” clause to aid in validating the messages that should have flowed between nodes. This simple and almost obvious idea, leads to the following Cucumber scenario (leveraging Eugene’s sample):
Scenario: Add two limit orders to the SELL order book, with more aggressive order first When the following orders are added to the "Sell" book: | Broker | Qty | Price | | A | 100 | 10.6 | | B | 100 | 10.7 | Then the "Sell" order book looks like: | Broker | Qty | Price | | A | 100 | 10.6 | | B | 100 | 10.7 | And the Message flow looks like: @startuml actor BrokerA actor BrokerB boundary MatchingEngine BrokerA --> MatchingEngine: LimitOrder BrokerB --> MatchingEngine: LimitOrder @enduml
As you can see, the Cucumber scenario effectively allow me to validate the completion state and also the messages passed to create the state. For particular types of distributed application that build on Finite-State Machines (FSM) in a globally distributed application this scenario allows a certain level of confidence based not only on state but also the messages passed on the WAN/LAN to construct the state at each node.