Using BDD with a system comprised of multiple services 1 view 

[Harrison Brown]

How do you go about applying BDD to a system that comprises multiple services? 

We're developing a system at the moment that requires orchestration between a few different services to achieve one business outcome so our options seem to be (a) write BDD scenarios at the service level in their respective Git repositories, describing only their own behaviour, or (b) write BDD scenarios at a level higher in a dedicated repository and describe the behaviour of the whole system.

Option (a) has the obvious downside that lots of the behaviour the business cares about involves multiple services so the BDD scenarios are anaemic, but option (b) is a pain to automate because the test code (we use Behat) can't easily reach 'inside' any of the individual services to set up our Given steps.

If anyone has any thoughts, however brief, on this — or could point me to a book/article/video on the subject — I'd be grateful.

Thanks,
Harrison

[Galibier]

You can do both. The important things are too

1. Choose the appropiate level of abstraction, so you can clearly describe the what and why of the behaviour without describing the how

2. When implementing the higher level scenarios just cover the fundamental behaviour (avoid exhaustive testing) and develop a strategy for setting up state.

When using external services with higher level services you have several options to set up state.

a) Write an `ideal` fake service which you use to drive the development of the higher level consumer (useful if the underlying services don't exist yet, or is under development, or is constantly changing)

b) Use the public api of a test implementation of the service to set up state

c) Use something like VCR to record responses from the service and use the cassettes to deliver state.

You can combine these techniques to meet your particular needs. Note that you don't need to reach inside the service to create state. You should just be using the public api that the service provides. If the service can't create state, then just record it with some state in it, and modify your Given's language to ask for that particular bit of data.

BDD is about describing behaviour. This can be done no matter HOW you are implementing the behaviour. How your software its architected is irrelevant to describing and driving the behaviour. If you are doing BDD correctly you are describing the behaviour BEFORE it exists. If you are testing after the fact then you can apply the same techniques, but often it is harder because you let your understanding of HOW things are implemented infect your scenarios. This results in scenarios that have to much detail in them and are often difficult to implement, because the detail gets in the way of discovering the fundmental abstractions the concisely describe the behaviour. Without these fundamental abstractions creating state can seem more challenging than it actually is.

--
You received this message because you are subscribed to the Google Groups "Behaviour Driven Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to behaviordrivendeve...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/behaviordrivendevelopment/14fa9b34-f14d-4f77-90df-0257855f1657n%40googlegroups.com.

--

------------------------

Andrew Premdas

blog.andrew.premdas.org