If later I notice I have to reject future dates, consider the month of the year, or whatever other constraint or feature, I just repeat the whole iteration.
I think in TDD even for such a small thingie as the AgeCalculator, you use different RGR-iterations.

About the multiple tests: for adding features such as fe a date to calculate against, I start with a new test.
When starting with -extensions- (such as reject future dates), I have two options: Add a new test, or refactor the old test, depending on what you need to do.

The amount of tests I create doesn’t really scare me, what scares me is having useless tests

Thank you for submitting this cool story – Trackback from DotNetShoutout…

I would change this:
“1) Think => how should you write your test?”
to:
1) Think => how do I know if I got it right / if it is working.

The thing is it isn’t revealing the purpose of that step. It is not a about looking for a test without a reason. It is about looking at how we can verify the new functionality. It is just easier to be guided that way:
How do I know if the age calculation is right:
- it works in a normal case such as x.
- it rejects future dates
- it considers the month of the year
- it doesn’t confuse the month of different years.
…

I am not saying write all at once, just that in each TDD iteration that would be the best first question to ask.

Of course thinking on the question up-front does the reveal what you are about to code wasn’t that simple at the end and you want to use already tested stuff for the date calculations – so you don’t end with a huge amount of tests