> <i><p>A test is not a unit test if:</p> > <li>It talks to the database > <li>It communicates across the network > <li>It touches the file system > <li>It can't run at the same time as any of your other > unit tests > <li>You have to do special things to your environment > (such as editing > config files) to run it.
If you don't know Peter Deutches 8 fallacies of distributed computing, then you'd probably feel really good about not testing your applications ability to handle partial failure. It may feel like it's slowing you down early on, but at some point, you really need to have real world tests that put your application under really heavy loads to test concurrent data structure access. You also need to have fault injection capabilities to stress the failure handling code to make sure idempotent behaviors are true to form. There's lots of reasons to interface to a real-world environment. It might not be in your unit tests, but you should have a plan, during design and coding on how you are going to instrument and inject for real-world testing.