Clearly not a style which works for any and every applications. Still, it's definitely a good thing to aim towards such an architecture. It brings really nice properties in terms of testability and safety.
Indeed, the terminology has been greatly confused. I think I'll die on this particular hill though. I think it's important to name things properly. That said the trick of going through a verb might just work?
This is an interesting way to frame the conversation around pair programming (and TDD even if only alluded to here).
Finding the right level of abstraction for the tests is important indeed. It helps keep them useful longer. Scope and complexity are linked and can help find the right balance of tests.
This is a nice update on the criteria you want to have in mind for good test suites.
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.