This needs repeating but yes, quality matters in test code too.

Nice approach to stub standard types in Rust. The article is a bit confusing the different types of test doubles though.

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.

There's a need for clearer vocabulary about testing indeed. The write up is a bit dry here but that's a start.

There's a big "if" of course, don't just throw your tests out of the window. But indeed, they need to bring value... so start by having really good tests.

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.

Or why meeting targets is not what you want. It's still a good guide though.

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?

I'm using the term regularly when dealing with legacy code. Finally remembered when I saw it first.

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.