testing of the human element is good as well. run scenario of typical/expected failures and test the procedures for handling them.

Here are some opinions I wrote down yesterday, which happen to be disjoint: * Tests aren't always useful. There are legitimate reasons to avoid automated tests in some situations. * Testing first is a great way to get into the habit of writing tests. But the key is the tests, not when you write them. * In each test, take care to separate the thing being tested from setup and checks (I hadn't heard of AAA; thank you) * On conventional stacks, try to write code in a way that minimizes the need for testing I/O (my Mu is designed to eliminate this bullet) * On conventional stacks, test one piece at a time more than whole assemblages (also "called 10 unit tests for every integration test"; again obsolete on Mu: http://akkartik.name/post/tracing-tests) * Never DRY tests, only production code. With tests it's more useful to be able to see everything at a glance. If the test is too long, perhaps you need better interfaces in your production code. * Coverage is useful as a signal to check once in a while. It becomes less useful if you constantly look at it. If you happen to look and find that coverage is low, focus on doing the above bullets more diligently. 100% coverage is not desirable.