Your example of TDD is poor for many reasons, but I'm going to focus on just two
REFACTORING
Refactoring is the soul of TDD; it's the space where we think about what we've done and what it means, what is my code trying to say about the problem. We get to be creative, we think of algorithms, we think of better ways of expressing the solution.
What we don't do is immediately pivot to writing a table and then using the tests to 'debug' it. Maybe we will have a table at the end of our iterations, maybe it'll be a big switch statement - or maybe there really is an algorithm. Who knows? But we should build up slowly, one test case at a time, as we discover and learn more about our domain and the code we've written.
ONE TEST AT A TIME
But what's worse is that you're essentially writing code to a specification written by someone else. That someone else is you. Just grinding through until a specification is fulfilled removes the space for reflection about the spec (is it right?, can I improve how it's expressed) that would come with refactoring.
What you're doing isn't TDD - it's writing all your unit tests first. You need to go slower, much slower, write less tests up front, and place refactoring at the heart of your practice.
Agree about the less tests.
I could have tested one date at a time.
I would also argue I did refactoring. The first approach of the algorithm was to add 56 years. It did not worked, but not in all cases, so I made it smarter.
By now I found an other edge case where the algorithm does not work, so I will add a test and refactor the algorithm till it works correctly.
Or do you mean something else by "refactoring"
"But what's worse is that you're essentially writing code to a specification written by someone else."
I don't quite understand what the problem is with that. There is a requirement ans I try to solve it with the code.
hmm OK, I see. But for that I first need some code that does work and where the tests pass. After the tests pass with my (ugly, not optimized, not perfect) code I can start refactoring in the sense of changing code without changing the behaviour.
Where in TDD does that step come?
Your example of TDD is poor for many reasons, but I'm going to focus on just two
REFACTORING
Refactoring is the soul of TDD; it's the space where we think about what we've done and what it means, what is my code trying to say about the problem. We get to be creative, we think of algorithms, we think of better ways of expressing the solution.
What we don't do is immediately pivot to writing a table and then using the tests to 'debug' it. Maybe we will have a table at the end of our iterations, maybe it'll be a big switch statement - or maybe there really is an algorithm. Who knows? But we should build up slowly, one test case at a time, as we discover and learn more about our domain and the code we've written.
ONE TEST AT A TIME
But what's worse is that you're essentially writing code to a specification written by someone else. That someone else is you. Just grinding through until a specification is fulfilled removes the space for reflection about the spec (is it right?, can I improve how it's expressed) that would come with refactoring.
What you're doing isn't TDD - it's writing all your unit tests first. You need to go slower, much slower, write less tests up front, and place refactoring at the heart of your practice.
Agree about the less tests.
I could have tested one date at a time.
I would also argue I did refactoring. The first approach of the algorithm was to add 56 years. It did not worked, but not in all cases, so I made it smarter.
By now I found an other edge case where the algorithm does not work, so I will add a test and refactor the algorithm till it works correctly.
Or do you mean something else by "refactoring"
"But what's worse is that you're essentially writing code to a specification written by someone else."
I don't quite understand what the problem is with that. There is a requirement ans I try to solve it with the code.
Refactoring means changing the code without changing behaviour.
Every example you gave of refactoring there changed the way the system worked (so not refactoring)
This might help quii.dev/The_Tests_Talk
hmm OK, I see. But for that I first need some code that does work and where the tests pass. After the tests pass with my (ugly, not optimized, not perfect) code I can start refactoring in the sense of changing code without changing the behaviour.
Where in TDD does that step come?
From the link I sent you above
If you want a more involved tutorial read github.com/quii/learn-go-with-tests