Making It Better With Test-Driven Development

I use TDD (and more generally: automated testing) as a method to improve the efficiency and quality of my work as a developer and I advocate for my teammates at Philosophie to do so as well. But I’ll admit that I didn’t always feel this way. When I first started with automated testing, I believed that the following common myths used in arguments against TDD were true. Only with experience did I realize how wrong I was — so my goal here is to share this realization with you.

Myth #1: It’s expensive and slows down progress

When you first get started, yes; writing tests will slow you down. You’ll be thinking, “it’s 50–100% more work… I have to build it, and write tests for it!” But just because you’re inexperienced with the technique doesn’t mean it’s inherently inefficient.

When you master it — the approach, thought process, tooling, etc — testing will become second nature. Rather than something you tack onto a task as an afterthought, it becomes an integral part of the way you do the work. You’ll become so efficient at writing tests that time to complete a single task will actually decrease as the benefits of having tests in your workflow will begin to show even within small units of work.

You’ll find that your thoughts are clearer. Your work becomes self-documenting so your mind can be free to explore new possibilities without the fear of losing a previous train of thought (and paying the price to return to it later). It’ll be easier to think through diverse cases. And, perhaps most importantly, your tests will prove to you that your implementation works as you write it, in a matter of milliseconds — no more writing to stdout or stepping through your implementation in a REPL or debugger to manually check its correctness (not to discredit these tools: they can be great resources for exploration and debugging).

Myth #2: It limits software design thinking to the micro level

I hear people say that TDD has negative consequences on software design and architecture because it forces you to focus on the micro level (classes, methods, etc) and neglect the macro (architecture). That may be true for some people; but those people are doing it wrong. Unit testing is not an excuse for big picture thinking and software design.

You should still use whiteboards, scratch paper, documentation, etc to ideate and collaborate on the bigger picture. Don’t be afraid to pseudo-code or even go down paths of prototyping implementations to get your ideas out in code and see how they feel. When you find a good design — something that fits — begin to break it down and let TDD shine as you explore implementations and think through specifics.

While testing may feel painful when you first get started, don’t let that prevent you from giving it a real chance at improving your workflow.

Let’s recap some of the benefits:

• It helps you reason about your code.
• It allows you to experiment with and explore implementations with a rapid feedback loop.
• It forces you to consider and document many cases.
• It allows for refactoring (both now and later). Cost to refactor is high when test time is slow (i.e. manual); automated tests provide fast feedback to ensure interfaces still do their job after their internals have been refactored.
• It helps to onboard new colleagues. Test cases provide living documentation and example usage.

And I’ll leave you with a word of warning: while unit tests can certainly help to catch issues and regressions, they won’t guarantee the validity of your system in the same way E2E testing will. Don’t think “every unit is fully tested, therefore they must work when brought together in an application.” E2E testing and manual QA are tools to guarantee your application works for your users. TDD is a tool to improve developer efficiency and code quality.