Beyond TDD....to BDD?

It's been a while since I posted anything here - I've moved jobs recently so the last few months have been taken up with settling into the new role.

I've been thinking a lot about test-driven development recently and whether it's always the best approach, or if there are variations on it that are better suited to some applications. When I first started using TDD I was writing software to run risk and cost-benefit models, which were generally perfect for a test-driven approach. The calculation could be broken down in sub-calculations, each of which would be implemented by a single method, with related calculations grouped into classes. Each sub-calculation could then be unit tested and whole thing usually worked out beautifully. They were almost textbook cases of when to employ TDD.

Recently I've been developing much more standard line-of-business applications, heavy on CRUD, with a small amount of complex business logic, and doing TDD just feels like going through the motions, with little benefit gained from it.

What I've decided to do is start researching behaviour-driven development (BDD) as I think it will be better suited to the kind of systems I'm developing now. Plus it will be fun to learn something new!

My companion on this adventure is the Manning book BDD In Action, which I'll be reading on my commute to and from work. I'm also going to document my progress right here! It will be an opportunity to order some of my thoughts, plus a great way to measure my progress.

Watch this space for the first instalment!!

Testing IoC Containers

Just a quick post now that I'm back from a Christmas break.

One of the tests that I always write in my applications is one to check that my IoC container is configured properly. This is something that is often neglected and I'm not sure why.

It's just as case of writing a test (or tests) to try and resolve every 'entry point' class in your application. For example, in an MVC application you would test that each controller can be resolved. Any dependency that hasn't been registered in the IoC container will then cause a test failure, informing you at compile-time that you have an issue (rather than it rearing its head at runtime).

To take it to the next level of detail you could have a set of tests that verify that each registered depenedency resolves to the correct type, however I've never felt the need to take it this far.