Technically you didn't follow the tight TDD loop of only writing as much test code as necessary to produce a failing test. Instead you wrote multiple test cases and proceeded to fix them all at the same time (multiple being each of your 'convertedDates').
This is still way better than writing tests after the fact, or worse still not writing tests.
Yes you are right, thank you for the comment.
I could have splitt the test cases more. E.g. first test a year conversion, then a month conversion, then a day. And fix the problems between the tests. Also more scientifically correct would have been to test a single date only, fix it, test an other date, etc.
On the other hand one could argue I have only tested correct dates. Next iteration should test incorrect Gregorian dates, the one after that, dates that are outside of the provided table, etc.
Technically you didn't follow the tight TDD loop of only writing as much test code as necessary to produce a failing test. Instead you wrote multiple test cases and proceeded to fix them all at the same time (multiple being each of your 'convertedDates').
This is still way better than writing tests after the fact, or worse still not writing tests.
Yes you are right, thank you for the comment.
I could have splitt the test cases more. E.g. first test a year conversion, then a month conversion, then a day. And fix the problems between the tests. Also more scientifically correct would have been to test a single date only, fix it, test an other date, etc.
On the other hand one could argue I have only tested correct dates. Next iteration should test incorrect Gregorian dates, the one after that, dates that are outside of the provided table, etc.
It's actually very important that you write one test as a time, make it pass and then refactor.
Doing large chunks is how a lot of people get in to a mess.