Thanks for the write up, it seems balanced and well thought out.
I'm a big proponent of TDD but I'd suggest adding one case to the Don't use TDD set. When you're learning a new technology/framework. I've previously made my life harder by trying to fit my ideas of how to write tests based on previous experience onto a new Technology only to find that once I understood the technology then I could understand the testing paradigms that went with that technology.
Thanks for the write up, it seems balanced and well thought out.
I'm a big proponent of TDD but I'd suggest adding one case to the Don't use TDD set. When you're learning a new technology/framework. I've previously made my life harder by trying to fit my ideas of how to write tests based on previous experience onto a new Technology only to find that once I understood the technology then I could understand the testing paradigms that went with that technology.
That’s already covered under “If you’re unsure of what you’re building”.
But in general for frameworks I would make sure you’re at least wrapping them in abstractions so you’re not completely coupled to them.
Also a very important point.
Thanks for bringing this up. This is probably worthy of a blog post on its own as there are at least a couple of related considerations: