A Real World Example of BDD

Behavior Driven Development (BDD) is a great way to organise your development. Creating Executable Specifications helps us to guide our work, but what does that look like in the real world on a real project delivering real software? In this episode, Dave Farley shows some real-world BDD examples. Acceptance tests from Adaptive, a London-based FinTech company building high-performance trading systems.

These kind of executable specifications, focused on the desirable behaviour of the system from the perspective of a user of it, help to steer development and so off guide-rails that structure the software engineering of great systems.

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

🎓 CD TRAINING COURSES 🎓

📚 BOOKS:

📖 Dave’s NEW BOOK "Modern Software Engineering" is now available on
(Paperback version available soon)
In this book, Dave brings together his ideas and proven techniques to describe a durable, coherent and foundational approach to effective software development, for programmers, managers and technical leads, at all levels of experience.

📖 "Continuous Delivery Pipelines" by Dave Farley

📖 The original "Continuous Delivery" book by Dave Farley and Jez Humble

📧 JOIN CD MAIL LIST 📧
Keep up to date with the latest discussions, free "How To..." guides, events and online courses.

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

CHANNEL SPONSORS:

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

LINKS

[hdjksa]

Thanks for this video. You really helped me with writing my scenarios.

[lolpez]

Would be awesome to have episodes of real World examples of bdd!

[brugh]

I was just thinking that you should make this kind of video. I would like to see more examples how you would ideally write non-trivial acceptance tests. Thanks Dave!

Also, I'm a bit confused with test type naming as different people use different definitions for a different type of tests and would like to hear how you view the testing pyramid and what each test type should focus on

[adrianperez]

Thank you for this real world example. I will be sharing this video with my team on Monday to start a conversation on which areas we can improve in, if any. Every example of BDD style acceptance testing I've ever seen is by necessity too trivial to be of any use in driving any real conversation about any benefits/pitfalls to these approaches.

[dosomething]

Wow. Your criticism serves as a test for me:”Can I find the error in the example?”

[amitev]

Very insightful video. Analyzing existing specs and adding value on top of them is a very good idea. I would like to see other examples of tests covering a rather complex business logic and how the testing is being approached in such situations. Best regards!

[stefanogustinelli]

Great content. I've been wondering for years if this would ever work in real complex scenarios. All the times I saw just unit tests or integration tests written in Gherkin.. It would be great if you could share some common patterns or strategies to write executable specifications correctly ( the What, not the How)

[RedBeardedRabbit]

Excellent vid!

Few thoughts I've been mulling over:

1. How can I make a convincing case at my company for using more BDD testing at the Component and API level (in a white-box fashion) as opposed to the usual UI-level where I see them used - because the latter is far more brittle, slower to run, etc. I think our BDD tests need shifting to lower levels of the test pyramid instead of where I usually see it - at the very top.

2. To what degree should we use "test doubles" (for isolating ourselves from external services, make our tests faster and less brittle) to run such Component, Integration, API tests? Martin Fowler would probably say - most of our tests should use test doubles - and I would agree! And yet, Due to this added complexity, I find it very challenging to get developers/teams to do this kind of testing and I see organizations just end up doing the testing "ice-cream cone" where acceptance is done via automated UI tests (or manual!) instead of lower in the test pyramid.

3. What is the lowest level at which BDD tests make sense? "Unit" and "Component" terms are debated, but I think even at these lower levels I see possible value of using BDD.

[MrAbrazildo]

8:17, once I had a serious 8-days-to-catch bug (more than 1 day for me is rare), the longest in my life, as long as I remember, due to using explicit number instead of a word representing it.
10:50, from a technical point-of-view, macros could reduce this code nicely. And I would not switch a String, I would use numbers instead (global named constants), which are way faster and safer, if you consider case-sensitive and other tricky strings pitfalls. And I would not 'throw' anything, which is slow and gives nothing in trade.

[finnwillows]

These tests look similar to David Parnas's requirements for the a-7e aircraft. The whole idea was that pilots could read and review the tests, so the tests could only talk about things pilots understood.

[skipbalk]

Please consider your 'highlight effect' to be less sparkly, as it makes the highlights actually quite hard to read :)

[davidmaes]

Thanks, I've been looking for how to set up stuff without clogging your Given. The background thing gives something to look at. Am I right in assuming this is where you can set up authentication/authorization as well? To make sure you are the subject of your story?

[gonzalowaszczuk]

It seems much of the complexity and "hard work" is pushed to the DSL and lower layers. What is your advice on maintaining said DSL?

Should each developer that works on each use case modify this DSL freely? Or should it be something a little more stable that requires a more thorough review from the team or a technical lead?
If the DSL is modified in every user story, is this an indicator that things are being done correctly, or badly?
What good practices are there for maintaining the internal test DSL? For example, how to prevent modifying the DSL for one test case making it fail other unrelated test cases.

[dosomething]

Can we have access to download the code samples?

[luxnox]

Im surprised you didnt call out multiple Then statements in a scenario as problematic or an anti-pattern.

[alirashidi]

video has low quality, texts are barely readable