In a large codebase it's not a given indeed. That's why you want integration tests to get there.

This is maybe the property of tests which is the most easily misunderstood. It's not always easy to respect it as well.

A very long read but contains lots of insights. Goes from two very famous security related failure, to highlighting how a test first approach could have helped. It then finishes with a long section on how to foster a testing culture in an organisation.

This is definitely a skill which is hard to teach an learn. When it sticks it brings really nice results though...

A bit old but still relevant. Don't focus on tools or the fashion "du jour", instead have a set of timeless principles and evaluate your work against them.

A little introductory article about putting an ATDD cycle in place for your development.

Maybe a bit extreme as an example, but highlights quite well why you want to limit logic in tests as much as possible.

Apparently in the age of people using LLMs for their tests, there is a bias toward mockist tests being produced. It's a good time to remind why you likely don't want them in most cases and limit the use of mocks to consider fakes and checking system state instead.

This is an old one but still a funny way to approach the question of test coverage. Unsurprisingly, the context matters.

A good debunk of that claim we sometime see. Of course the tests need to be designed and you need to have good architecture blueprints to follow, otherwise you'll be in trouble... TDD or not.

When you realize TDD is about units of behavior... then you can see what can be iterative and what can't in your process. In other word, what is dictated by the problem domain is iterative, what is dictated by system architecture is not. Luckily, the latter is often related to the user experience you're aiming for.

The design proposed is a bit too clear cut for my case. Other than that it's fairly aligned with what I preach.

A nice little survey of what the academia already had to say about TDD a few years ago. Clearly the outcome seems mostly positive.

Yes, tests can follow patterns as well... and antipatterns too. It's good to name those antipatterns, let's avoid them shall we?

This is one of those workshops I like to do with teams from time to time. Didn't do it for a while. I wish this resource was on a safer space than google docs.

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.