All the code is tested. All tests are green. But you are at a point where you cannot possibly continue.

To finish the current feature, you would have to change all your code, breaking several tests. You wrote yourself into a corner.

What do you do now?

Intro (TL;DR)

Sometimes we go down the wrong path. And then we get stuck. That can happen with any approach to implementing software - also with test driven development.

This is part 5 of an 8-part series about the beginning of the TDD-cycle: The steps “Red” and “Green”. I am David, an among other things, I teach TDD to developers and teams.

When you get to a point where you cannot continue, change direction slowly or take steps back.

Changing direction slowly means refactoring. Change the tests a little, then the code, then the tests, and so on, until you can continue again. Keep the tests green all the time.

Or take steps back: Delete tests and code. Undo some work until you get to a point where changing direction is easy again.

Question / Problem

When doing TDD, we break down a larger problem into very small steps. And usually we do not even plan all the steps ahead (that would be too expensive most of the time) - We change direction as we go.

This does work surprisingly often. But sometimes it does not. Sometimes we end up in a place where reaching the original goal - solving the original problem - seems harder than an hour or a day ago.

Our instinct, as programmers, is often to move forward. Debug the code. Add more tests. We cannot throw away the tests. Finish the feature with the current design. We already spent so much time on it.

But this is often the wrong approach. We are falling for the “sunk cost fallacy”-

Solution

We could change direction slowly. Keep the tests. Refactor the code and the tests. Slowly change the design until we are at a point where we can continue again.

But this is also a way forward. It is often a waste of time.

Why not just go back? Revert your changes. Or delete the code and tests you wrote. Go back to a point where things looked better and start over again.

How can that possibly be cheaper? Throwing away the code and doing the work twice?

Well, you throw away the code, but you keep all your learnings (maybe write them down). And when you solve the same problem a second time you will be much faster than the first time.

But to be able to go back to a place where things looked better, you need “Save Points”. Commit often. You can commit every time your tests are green.

Like in a video game, where you save before you get to the hard passage.

Use that. Don’t worry, you can squash those commits later.

Conclusion

Throwing away some work and starting over again is often cheaper than debugging a problem or trying to get out of a corner by moving only forward.

When things do not work out as you would have liked, when you end up in a place where going forward looks difficult, consider going back.

Don’t be afraid of deleting tests or even production code.

CTA

Have you been in situations like I described in this video? How did you get out?

Please tell me in the comments or on Twitter, where I’m @dtanzer.

And if you liked this video, please subscribe and share it with your friends and followers with the share buttons below - That would be awesome!

Read / watch all parts of this series here: