Git bisect won't help much for flaky tests... but maybe this bayesian approach can.

I vehemently agree with this piece. Fakes are unfortunately underrated. They're the most powerful test double, I wish more projects would invest in them (can be quite an investment, which the article doesn't quite show unfortunately).

This is indeed very important to ensure the tooling around your project supports running the whole thing locally. Too often projects sacrifice the ability to do this, it's clearly a hindrance to testability and a short feedback loop.

You'd wish more projects would put such measures in place.

It's been a while that I started to consider the test pyramid as fairly limiting for our thinking about tests. The dimensions proposed here give a more comprehensive model to reason about.

Interesting shell based test framework targeting pure POSIX. This makes it fairly portable. It feels a bit raw but there are a few interesting ideas in there.

Still young but looks like a nice option to write GUI tests for Qt based applications.

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.