Another space with rampant enshittification... No wonder users are jumping between alternatives.
This is indeed a very good option to have when you make a command line tool.
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.
Neat little Python trick for testing exceptions.
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?
The definition of ready can be a big help avoiding too many questions about stories as they are implemented. They should be clear before hand.
Where are acceptance tests coming from? They're generally the result of a conversation.
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.
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.