alt Hacker NewsHaving thought heavily and even presenting on exactly the same topics, looking at the ToC, your book seems to cover the basics well.
However, since we are talking about effectiveness, applying a lot of these principles might lead to a non-maintainable codebase — for humans and LLMs alike.
When any change causes 500 tests to break, or it causes nothing to break (see monkey-patching and/or mocking), you've gotten to a point where your testing approach is ineffective.
Most start applying principles of just enough tests and testable architectures too late, yet I believe they are fundamental.
Do you cover these in your book?
My experience with refactoring is if a change causes larger number of tests faults, I run the last failed test and fix that (see my AGENTS.md posted elsewhere). Generally, if you fix the one issue everything else falls in line.
Wrt mocking. I'm not a huge fan. Again, look at my AGENTS.md. I prefer monkeypatch as a last resort option. Luckily, if you use TDD, you rarely have to use mocking. If you don't use TDD...