This is how I build now: Build it -> Refactor it -> test it (to be honest not all the time)
My question is how to incorporate TDD into that? I usually get consumed with the problem and just focus on solving it first
Sadly using TDD would require you to change how you work. TDD is a cycle of Red-Green-Refactor. It consists of writing the specification for some behavior—red, due to a failing test. Followed by writing the code that satisfies the specification—green, the tests pass. Lastly, refactoring, changing the structure of the code without adding or removing behavior.
This cycle Red -> Green -> Refactor (Repeat), is simply a different flow of working. One downside to this approach is that I don't always know what I am supposed to build. When I don't know how to solve a problem, I will write a Spike.
A Spike is an implementation that is an experiment. Before I start a Spike, I write out what I want to learn, and I commit to deleting all of the Spike code once I have learned that information. With the information in hand, I would use TDD to create the real implementation.
Since TDD is so different from your current workflow, I am not sure how you could mix the two styles together. At the end of the day, TDD is my preference and it is up to us individually to discover how we work best.
Thanks for the question!
Thank you for the detailed answer!
I will try out working in TDD and see how I like it.
My fear is always just time, but if TDD makes me have less bugs then I am ok with the time sacrifice
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.