A good reminder of the reasons why the organization of your tests shouldn't necessarily match the organization of the application code. You don't want fragile tests, do you?
A good reminder that the complexity of tests should be as low as possible.
Both TDD and design docs complete each other well indeed. They just don't focus on the same activities in the project. That said, both later provide important insights on all the decisions taken to produce some code.
Even if you do use mocks to isolate your tests, at least don't nest them.
A quick summary of the different properties you want in tests. In practice you'll likely have to find a tradeoff among them.
This explains quite well how TDD is made of several cycles of different length.
There are many opportunities to redactor. This one is aligned with Kent Beck's quote: "first make the change easy, then make the easy change".
A bit long and dated for a some advice. Still it does a very good job going through all the different type of tests you'll want to find on your project and how they're structured.
A reminder that the technique goes back to way before XP.
Good reference to get an idea about what we should be considering when we talk about unit tests.
Yes, there's plenty of room for design in a TDD cycle. This is a good explanation of when it happens and the challenges you can have doing so.
Indeed a good reminder that TDD might not be possible to properly apply at the physical boundaries of the system.
Struggling with TDD? Really feel like you need to write the implementation first? This is a fine approach. One caveat though, you have to be very disciplined in the way you uncomment the code, otherwise you'll quickly loose the benefits.
Nice post. Explains well why the answer is not a number to target. You want to impact the distribution.
Nice little paper I overlooked. I agree with it obviously. More tests are not a free pass to let complexity go wild. Architecture and design concerns are still very important even if you TDD properly.
Very interesting discussion weighting the main differences and disagreements between a Philosophy of Software Design, and Clean Code. I read and own both books and those differences were crystal clear, it's nice to see the authors debate them. I'm a bit disappointed at the section about TDD though, I think it could have been a bit more conclusive. It gives me food for thought about my TDD teaching though and confirms some of the messages I'm trying to push to reduce confusion.
This is a good satire which shows well the excuses people use to not test first.
Pointing out an important dilemma indeed. Which tests to keep over time? What to do with redundancies?
Indeed, it is often overlooked that TDD can really help finding a state of flow. Unlike other addictive activities presented in this article it requires a non negligible initial effort though, that's why I wouldn't describe it as an addiction though.
Starting from a wrong analogy to raise real thinking and questions about TDD.