Strongly disagree with #4. It's incredibly time-consuming to write code that will be refactored away in mere minutes because I know it will need an abstraction or the code fits nicely with a particular design pattern. The concept that you haven't cleared an invisible barrier yet doesn't justify claiming YAGNI applies.
It's test driven design, not test first design. Write as little code as you can justify. I don't need to wait until I do something the second of five times to create the abstraction.
This is one of those dogmatic practices that makes TDD seem like a pipe dream to many.
This is one of those things that's impossible to test and therefore prove either side of the argument. From my perspective, the long-term savings by not assuming a particular design pattern and having to rip it out or maintain it is worth the short-term lose in rewriting a few lines of code.
Nevertheless, I do agree that YAGNI is not about intentionally handicapping your ability to write code.
I feel that the approach should be to consider how you need your tests to provide feedback. If I have a pattern or abstraction in mind ahead of time, it's not because I've never used it before. By writing tests assuming the abstraction, I can get feedback about it faster.
When I say that the rule seems dogmatic, it feels like the "simple rules" that we talk about driving TDD are far too simplified. They lead people to think that you have to waste time writing the simplest code possible, then once you get to refactoring you have free-reign to do whatever you need. It seems to me that everyone is better off if you take a more pragmatic approach to where you're willing to start the process.
As long as your tests help you decide if your implementation is appropriate, it shouldn't matter if the idea of the abstraction came first.
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.