Makes sense to use TDD for library/API code and BDD as integration tests?

Question

I am a complete newbie to BDD and I would like to understand where does it come into play in a development cycle. In TDD approaches, we would write unit-tests commonly for libraries or apis, we would mock objects and that was great because it could even drive our design. These tests would be written before the actual code which is nice.

I understand that BDD is more about spec/scenario testing and I can see that it is a perfect fit to test a business requirement against the actual code. But what is the best practice for writing these tests? Do we still keep writing individual tests (as in TDD) mocking out dependencies and writing unit-tests for every single thing that could go wrong? Then write our bdd tests? Do we write the bdd tests first? Do we write only bdd tests even against individual components?

I use .NET and usually write asp.net mvc apps but this is more of a theory question and independent of the underlying programming language.

Thanks a lot.

Answer 1

Don't know about the right way but this is my experience. After analyzing the specification document I try to extract as many different 'stories' and describe them using BDD stories files. As you already know every sentence should start with either one of three keywords given, when and then.

After translating the whole specification to BDD test stories I write a class that implement steps i.e. execute each one of sentences used in stories.

Next step is starting writing an implementation which will be called by methods that execute script sentences by setting initial state (given), state transitions (when) and checking the destination state of the app (then).

Whenever I need to implement an actual class method I use TDD to do a thorough testing in isolation.

Of course, in order to run the test part of the code that is not yet implemented may be temporarily mocked.