Erm this smacks a little of absolutism. In many cases you'll definitely want to test at a method level - if the behaviour of a single method is complex but its

Erm this smacks a little of absolutism. In many cases you'll definitely want to test at a method level - if the behaviour of a single method is complex but its not part of the API, if you want to test it properly, you'll likely still have to have a similar number of unit tests (to properly pinpoint a bug), you'll just need to move them up to the API level - and furthermore, the tests you need to come up with are far more complex, as they have to anticipate the outputs of each function call as well (in order to obtain the same coverage). It's correct that by reducing your number of units and making them more broad scoped, you potentially reduce the number of undetectable faults you are catching (but need not), but you also make crafting the input that detects the remaining faults much more difficult. The correct approach is (it seems obvious to me) to mix the two. Don't force tests to be on a per-method basis, but also don't neglect to individually test those methods that can be better tested by individual testing. It seems like common sense - following a policy such as this so rigidly clearly leads to either wasted time and inferior APIs or missed test cases - the former I believe the OP has discovered already, the latter I'm sure they'll discover in due time. http://www.quickmeme.com/img/0f/0fb4fa35fad1b9ed112dc7584f47c531cf14a1c3c55d64bed93d33d5330dfcd1.jpg http://www.quickmeme.com/img/0f/0fb4fa35fad1b9ed112dc7584f47...