TDD vs. BDD

TDD

In TDD (Test Driven Development), We focus on testing the each line of code written in each of the API’s and Classes in the given file. This may bring 100% code coverage as there are no codes written more than what is required to satisfy test cases, and there are no more test cases than to test a functionality. But, this kind of a testing poses a problem especially in long run. A code undergoes internal refactoring, realignment several times in its course of development. So, any test cases written in above mentioned fashion would break whenever a code undergoes a refactoring. In worse, the test cases will have to be refactored too to cope with current state of code.

BDD

So, the rescue is BDD (Behavior Driven Development). Each external API exposed has an expected outcome. Each API satisfies a bunch of specifications, outputs, behaviors. Regardless of internal implementation of API’s, what is more important is that they should behave the expected way. This can be best handled by documenting each expectation from each API, and drawing a clear specification out of it. The testing is done only on the behavior of a particular API, not its implementation specifics. Even if there are some global data structures, or state values to be verified in testing, the wrapper (mutator) code should be written which will fetch those values. No direct access to any variable or value is permitted. Everything, every access, every operation is performed through a well defined interface.

One good thing that comes to my mind is generation of stub code which can test each function defined in a given file. Each file is parsed, and for each API in that file, a corresponding test-API is generated. All comments are generated by default (by looking at arguments, and return types). Search for Cproto, if there is no such framework, you will have to write your own.