- Posted by liammclennan on March 18, 2009
Since I discovered the beauty and clarity of BDD I have naturally been trying to write all of my tests in the BDD style (establish context, execute, assert observations). What I have found is that this style of testing is not always suitable. Because BDD is expressed from the end-user's view point it is not an efficient way to test component implementation. Doing so necessitates setting up a lot of uneccessary context.
BDD tests are supposed to be expressed from the point of view of the end users of a system. A single end user transaction will often have many complex sub-components involved. Testing the sub-components in the BDD style requires establishing a large number of slightly different contexts. I have found that it is not worth the effort when the sub-components can be tested directly.
My strategy is to use BDD to test the variations that are valid from the users point of view. If I was testing authentication scenarios I would have a BDD test for a successful authentication and a BDD test for failure authentication. Every other scenario, such as testing that authentication fails if the database is unavailable, is a test of the authentication sub component and it should be done in the traditional TDD style.