4 ms·
It sounds a little like you are trying to write all the tests to the spec up front? With TDD you are still allowed to change design choices as you go and as you
by majikandy 4y ago
It sounds a little like you are trying to write all the tests to the spec up front? With TDD you are still allowed to change design choices as you go and as you realise how you want it to behave. That’s why the tests are one by one. In my experience, TDD carries the most value when you really don’t know where you are going, you write the first test and you start rolling, and somehow you end up at your destination and people think you were good at writing code but actually the code was writing itself in a way as it evolved its was to completeness.
- Double_a_92 4y agoBut often you don't know at all how to best solve a problem, since the solution will probably need to touch many existing code units somehow. It might work if you are starting on some new, relatively self-contained feature...
- majikandy 4y agoSince you don’t know how to solve it, you first write a test that goes vaguely in the direction. If you can’t do that yet, you spike, mess around with it, get your bearings and some insight into where you want to go, try a few things out. Then, trash that and then write the first test as above. It almost always works, and excels somewhat in legacy code vs just changing things. It isn’t about ‘might work’. The TDD paradigm isn’t about finding shiny places where you can use. It is just a nice way of writing clean maintainable software in almost all areas. Places where TDD won’t work are usually by exception rather than the norm. Often those exceptions are where something already exists and wasn’t put in by TDD because by the definition of TDD you wouldn’t have been able to write that in the first place.