First some things I like: thinking about decomposing tests into subtests. Testing vs checking. Formalizing your mock objects.
This assumes that
1. All testing must put "design pressure" on your code, and
2. The design pressure from testing is sufficient to get good design.
So integrated tests are bad, QED.
The BIG problem: the "small" change? Having different win conditions for the human and the computer!
Agreed, but that's because the system can do a lot of things! That's why we use fuzzers and PBT and stuff to help generate tests for us. Systems are hard!
It's a neat idea! But I have two big objections:
1. His "contract tests" could be much MUCH better
2. This doesn't help at all with emergence.
require len(l) > 0
ensure len(l'new) = len(l'old) - 1
ensure out == l'old
Which is a problem, because code contracts REALLY nicely solve his "integrated tests" isolation problem.
I talk more about this here: hillelwayne.com/talks/beyond-u…