One thing that makes unit-testing code so hard is the way the real world keeps intruding. If all we had to do was code up tests for methods that sort arrays or generate Fibonacci series, life would be easy. But in the real world we have to test code that uses data-bases, communications devices, user inter-faces, and external applications. Have to interface to devices that aren’t yetavailable or simulate network errors that are impossible to generate locally. This all conspires to stop our unit tests from being neat, self-contained (and orthogonal) chunks of code. Instead, if we’re not careful, we find ourselves writing tests that end up initializing nearly every system component just to give the tests enough context to run. Not only is this time consuming, it also introduces a ridiculous amount of coupling into the testing process: someone changes an interface or a database table, and suddenly the setup code for your poor little unit test dies mysteriously. Even the best-intentioned developers become discouraged after this happens a few times. Eventually, testing starts to drop off, and we all know where that leads.