Software Development

Test Driven Design: at its best when it’s outside in

I’ve been playing around with rust for a few months – on and off. And I came to a halt without realising it and couldn’t get restarted.


Because I’d come to the hard bit – the business logic. What was this thing actually going to do and how was it going to do it?

And the truth was, I didn’t know. So instead of writing more code, I just stopped.

I’ve been trying to find an excuse for doing a TDD project. Because I have some experience, I know the one thing I don’t want to do is write any more code than I need to. I want to write just the right amount of code for my project to do what it needs to do.

So imagine my surprise when – on reading Kent Beck’s Test Driven Development: By Example – that I had everything I needed already.

I thought I might join an existing open-source project, or refactor one of the ones I’d worked on before. But in my nascent rust project I had the start – what I needed now was the design.

So I wrote a test or two and it felt good. But what next? At that point, I realised intrinsically that I need to go outside-in. Rather than building tests at the heart of the logic, I needed to build tests at the outside interfaces.

This article does a much better job of explaining it than I can. Suffice it to say, I’m unstuck. I’m thinking, I’m writing code. But also, I’m designing, and it feels AMAZING.

Related articles