You're not going to need it, and you should build the features & functionality you need by.
Kalle Tolonen
6.4.2024
What's TDD about [1]
List test scenarios you want to cover
Make one item on the list into a runnable test
Make code to so that the test (& all previous tests) pass (adding items to the list as you discover them)
Refactor to improve the implementation design
Rinse & repeat
Rules of TDD [1]
Thou shall not write any production code, unless required by a failing unit test.
Thou shall not write more of a unit test, than is required to fail (assertion failure/program crash/compile error).
Thou shall not write more production code, than is sufficient to make the one failing unit test pass.
Bullet points
TDD's tests provide a feedback mechanism: if something is hard to test, it means the code's design needs improvement [1]
You aren't going to need it is a good principle - don't build stuff nobody asked for [2]. Another way to describe this would be Elon Musk's engineering principles #1 (Make the requirements less dumb) and #2 (Best part is no part).
YAGNI failures are outweighted by their massive successes [2], so it's always safe to bet on less-is-more than the other when in doubt
Designing simple stuff
Simple stuff is quite hard to do. Every feature should pass tests, minimize duplication (Don't repeat yourself) & reduce complexity. TTD covers the first part well, so you should live by: DRY & great naming (methods & variables should tell what they're supposed to do). [2]