Often when working you will have an idea how to do something but be not quite sure how. This is very common with user interface code where you need to constantly show your work to an end user or designer to say ‘what do you think’. Other times are when you are new to a project or there is a new requirement that is notably different to things you have done before

In this world classical TDD is challenging. It is hard to write unit tests when you don’t have enough information to design the code. You are going to find things out about the problem and the solution very quickly

This is a good time to use a feature branch. Commit often. Explore. Don’t be afraid to rollback and throw away work. Your primary goal in this phase of work is to acquire the understanding needed to do the task. Unlike classical TDD you are likely to write a little bit of code and then a test or two.

In an ideal world after you have acquired the knowledge to do the task you would throw away your branch and start again but this time using the techniques recommended when you have Done it a lot before. It is perfectly acceptable to back fill the missing steps as long as you actually backfill the missing steps,

This is much harder than when using TDD, so be aware that you may actually be quicker to throw away your solution and use classical TDD. This is a thing that requires engineering judgement. The ease of writing your tests should tell you.