/ Unit Testing

Test First Drop Bear

I love TDD, but there could be a Drop Bare[1] waiting for you. The whole Red Green Refactor cycle is great but, can it be taken too far?

When I started coding Test First I had a hard time changing my mindset, for most of my programming life I just let the syntax flow out my fingers, then running it for validation. On top of the mindset difficulties, there seemed to be a lot of tedious code that I needed to write, back then I used TDD to define things like properties, their getters and setters on POCO objects in an application, I now see this as just wasted effort.

Lately, I have been asking my self, should I drive the definition of the Composition Root with tests? To answer this I needed to ask myself another question, Would I use TDD to define a configuration file? In the end, the Composition Root is (mostly) configuration. Personally, I don't see any advantage in defining the composition root test first for the same reason that I don't see any advantage in defining a configuration file test first, configuration only really changes which logical execution pathway will be used in your application at runtime, and testing these logical pathways is the important bit. If there is some logic in registering types, for example registering plugins when classes implemented IPlugin, the logic that found these types would be best built using TDD. At first, I thought this would be an exception to my answer of not using TDD when defining a Composition Root, but it's not, this logic is not configuration, its output is used to configure what plugins are available, not the logic its self.

So how then do you verify that your Composition Root is correct? Well, that is something that would fall into the realm of integration testing. Your DI container could also help to guard that things have been wired up correctly[2]. I rely on the fact that my DI container of choice (let's face it always Simple Injector :) works as per its specification and on integration tests, reserving TDD for building logic. At some point down the stack, you need to start to trust things because you can't see electrons :).

  1. https://australianmuseum.net.au/drop-bear photo credit: Kaptain Kobold cc ↩︎

  2. Call Verify when using Simple Injector, https://stackoverflow.com/questions/24153454/simple-injector-verify-in-production-code ↩︎

Aaron Job

Aaron Job

It all started at age 10 with an Amstrad 80386SX and a book. That book Computer Space-games made no sense to that 10-year-old but it kicked started an obsession with programming.

Read More
Test First Drop Bear
Share this

Subscribe to public abstract Gravy : Power