TDD testing application entry points

Question

I'm new to TDD, and quite like it so far (even though it's an adjustment process).

However, I'm struggling with how to go about testing the entry points to the application. By those I mean the main(String... args) method, a class whose single responsibility is to load and save a properties file from/to disk, etc.

When I was doing code first, this didn't seem like a problem. I just wouldn't write test for those kind of methods/classes. However, how am I supposed to follow the TDD process when there's code I have to write without tests?

In other words, when/how does writing the entry points fit into the TDD development process?

Answer 1

In most cases, you can't unit test the entry point, because, by definition, a unit test tests a unit in isolation from its dependencies.

In all but some trivial edge cases, the application's entry point is the Composition Root - that is, the place where all units are integrated. While you could perform a full systems test on the entry point, usually you should treat it as a Humble Executable.

My personal rule is that the Humble Executable can contain no logic (only composition), and I measure that with Cyclomatic Complexity; if the Cyclomatic Complexity of the Humble Executable is 1, it's okay not to test it.

However, although you can't unit test the entry points, you can still use Outside-In TDD to drive the composition, although you'd typically still need to replace some external services with Test Doubles.