3

I am trying to decide whether BDD is suitable for my project or not. I was reading about BDD here: https://en.wikipedia.org/wiki/Behavior-driven_development and here: https://agilewarrior.wordpress.com/2015/04/18/classical-vs-mockist-testing/

In the first link BDD is described as outward in, which is supported in the second link, which states that Mokists (who verify behaviour) assert from the outward in. Classicists apparently assert from the inward out.

BDD is often described as a combination of DDD and TDD. DDD advises me to start with the Domain Model and work outwards. Therefore why does BDD advise outward in? Am I suppose to start with the outer layer of the Onion i.e. UI, then work on the application service, then the Infrastructure and then the Domain Model last of all. I think there is something I am missing here. However, I have been thinking about it (and reading about it) for a few days and I have not found an answer.

9

Refer to the diagram below:

enter image description here

Notice that the TDD loop is "inside" the BDD loop; that is, steps 3.1, 3.2 and 3.3 of the TDD loop form the entirety of step 3 in the BDD loop.

That's what they mean by inside-out and outside-in. TDD-ists make assertions in the inside loop; BDD-ists pass acceptance tests in the outside loop.

The Onion is an architecture, not a software development process. It has nothing to do with BDD or any of the other DD's.

| improve this answer | |
  • 2
    Might also be worth noting that 1 scenario might spawn multiple unit tests. – candied_orange Feb 25 '18 at 3:56
0

DDD doesn't advocate either inside-out or outside-in approach. Rather it is focused on driving aspects of the system design and model from their real-life counterparts in the business domain you are attempting to model. DDD is concerned with modelling systems.

BDD does of course demand an outside-in approach and can directly complement the strategic aspect of DDD (which is concerned with things like naming concepts, ubiquitous language, communication and organization). Writing the examples/scenarios is both a BDD and a DDD practice. A collaborative technique such as Event Storming brings them both together nicely ad a form of business analysis.

The reason BDD implies outside-in is because it's central idea is to drive the development of the application from the required behaviour - the trick is to define this behaviour as formal scenarios or example (commonly in Given/When/Then format) that can be used to literally guide every step of the coding. These example need to be written collaboratively and can be developer iteratively before you start coding from them.

What you effectively end up with, if you have managed to write down several comprehensive examples/scenarios, is almost a domain model written out as gherkin scenarios. The code you then write - guided by these examples - effectively becomes your very domain model.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.