A listener to the Hansleminutes Podcast about Executable Specifications was asking me:
All of the examples of BDD I’ve seen follow mostly the happy path with only an occasional nod to the unhappy path and don’t seem to go into as many corner cases and essentially code coverage as unit tests too, but this feels incomplete.
Gojko also recieved the question and published an extensive answer on his blog: Duplication between BDD and Unit tests
My answer was the following:
One approach how I look at BDD is, that I do not look at it as an extension for Testing/TDD but rather an extension to requirements gathering.
The crucial thing from this perspective is to develop a shared understanding by working out concrete examples. Don't yet think about tests, ask you what would I write down in a specification, so that everybody understands what the system should do.
These are then the scenarios that you should strive to automate.
Later in the project you may add more scenarios to cover special cases/edge cases but it is not the goal of BDD to completely cover all possible paths through the system. For non-trivial systems this is usually not possible, so the challenge is to find the key-example that provide the most value regarding the shared understanding.
Of course this BDD approach is orthogonal to unit-testing/TDD. Here you rather strive for combinatorial completeness in the sense of code coverage.
interesting last sentence:
ReplyDelete"Of course this BDD approach is orthogonal to unit-testing/TDD. Here you rather strive for combinatorial completeness in the sense of code coverage."
If I get you right, you'd apply TDD and BDD in a complementary way? or do you BDD-adept drop TDD in favor of BDD?
I'd argue that a pragmatic TDD would not try to cover a100%. I consider 80% as an excellent coverage, everything above is probably not worth the effort (benefit/effort balance).
I personally (I'm not skilled in BDD so far, but I like TDD a lot) try to write tests for the main requirements (sounds a bit like what your BDD approach does) and the corner cases that will most likely arise (null-values, exceptions, etc.).
@André
ReplyDeleteYes I recommend using TDD and BDD together.
This can also be seen as two concentric feedback circles: The outer ATDD circle and the inner TDD circle.
You can find good discussions about this outside-in approach in the books "Growing Object Oriented Software Guided by Tests" and in the "RSpec Book".