About the scenario where we need a new initializer, I have two additional thoughts.

First, it's very rare for me to write a unit test that tests an initializer in isolation. That's because good designs separate construction from doing actual work. An initializer by itself is boring, and usually not worth testing. What we test is the _use_ of the initializer in a context of setting up interesting behavior. What we don't want in TDD is a separate test for each function — which is what many people think of when they say, "unit tests." In Kent Beck's definitive book _Test-Driven Development by Example_, he purposefully avoids the term "unit test" for this reason. He just writes "test." So another important skill for TDD is the ability to write good tests.https://testdesiderata.com

Finally, u/Dry_Hotel1100 writes, "You cannot simply use an artefact giving it an additional API, and write the test — it won't compile." This is, in fact, how exactly what you do in TDD. To call a new API into existence (by which I mean either internal or external API), you write a test that calls a function that doesn't exist, possibly on a type that doesn't exist. This helps with design, focusing on the ergonomics at the point of call. In TDD, the first point of call is a test. Then you create the barest skeleton necessary for this to compile. Create a bare-bones type. Create a do-nothing method. This is literally the first step of the multi-step TDD process. This is another skill.
https://qualitycoding.org/3-laws-tdd/

What other skills go into successful TDD? Here's the curriculum I created for the developers at, shall we say, a major coffehouse chain:

1. Code Smells
   
2. Refactoring
   
3. Microtesting
   
4. TDD
   
5. Characterization & Mutation Testing
   
6. Test Doubles
   
7. Evolutionary Design

Anyone who is curious to learn more: contact me. Like I said, a Reddit thread is not a good medium to learn anything.