Yes this is the best talk so far. Right now I am in a company that has strict class-method testing strategy. This makes refactoring a pain in the A and decreases the programmer time / quality insured by the test ratio.

In "unit testing", the unit doesn't mean "the smallest thing we test which we decided is a class even if doesn't make sense"; it simply means "on its own" so external dependencies are not in the way.

My heuristic for determining how much a test is worth writing is something like this:

cost of number of outbound dependence * human understanding complexity + non-immutability + how much code coverage it adds.

This leads to a grouping of tests and code that naturally fit together.