These notes came from some professional development training (June 2017) on behavior-driven design (BDD) and test-driven design (TDD). They focus more so on BDD, as TDD is more of a well-understood technique.
The premise for both techniques is that the code is secondary.
- TDD: write tests, then write code; more focused on the inner workings of the application
- BDD: write executable specifications, then write code; more focused on the outside behavior of the application
My takeaway is that TDD and BDD are techniques for making the specifications of how your software works more explicit by
- starting with the desired outcome/behavior first rather than just affirming it at the end, and
- having those specifications confirmed because of executable tests throughout the development process.
The primary benefit is what ends up being produced are more detailed acceptance tests, which improves communication among development, testers, and the customers.
It appears that the BDD area isn’t as mainstream/active (at least in .NET) compared to unit testing in general. Many of the Stack Overflow posts and blogs/articles that come up in search results are several years old (2010 to 2013). The Pluralsight videos, however, are more a bit recent (2014 to 2016).
The learning curve for whatever style/tool we chose would be intermediate. I’m not seeing something that would provide a very obvious path forward without a good deal of discipline or having to work around tooling that doesn’t help you “fall into the pit of success.” I get more of a feeling of “yes, we could technically do this,” but it probably wouldn’t be easy for a desktop application project. The tooling seems to be a bit more available for web projects.
Another concern is that the examples I’ve seen are often fairly trivial, which makes the concepts seem approachable. Once you start getting into more meaty application requirements, I imagine it would be tricky to not get lost in the technical “weeds” of matching the what (behavior) with the how (code).
BDD is more in line with an integration test (as opposed to a unit test). Therefore, there are more layers of the software working together to express demonstrable behavior. It is possible to use BDD without having all layers involved. For example, you can specify behavior for a chess game without any UI at all: http://www.daedtech.com/chess-tdd-23-yak-shaving-with-specflow/
If time allows, it would be useful to design a small but non-trivial application from the ground up using this design approach and tooling. It’s one thing to do a survey of the landscape (i.e., this document), and another thing to actually get your hands dirty and experience the process.
More information
This PDF summary goes into more detail of what I learned during my survey.
- Notes from a presentation on TDD/BDD as architectural tools
- Learning through search results
- Related (future) training
- Syntax examples