Unit testing is hard. There I said it. Although I have been developing software for the past 18 years I still find that putting my applications through their paces via unit testing is difficult. I have learned the lesson (I'm sure like many of you) the hard way. Unit testing is probably the most important part of software development. We all get caught in the trap once in a while when we believe that there is no need to test a piece of software we just wrote. We convince ourselves it is too hard to test, the rest of the application is solid, and that if there are any real errors in the code it will be discovered by the QA department. You know and I know this is a bad argument. Of course once the application is in production it is the piece of code that we didn't test that causes system failures.

There's no good reason for not unit testing all pieces of an application. Unit testing is the only way we can be assured that everything works as intended. It is the only way that others can take over our code, change it, and be confident that they didn't break anything unintentionally. Unfortunately fewer and fewer applications are truly standalone. Almost every application that I develop requires the interaction of third-party libraries as well as third-party systems. Creating n-tiered systems is not the exception anymore it's the norm. It's easy to test code that you wrote. You know how to control the inputs and you know the expected outputs.

What is not easy is testing the integration of third-party components and the range of their possible outputs. This is the case when interacting with Web Services, scraping Web pages, information providing systems, etc. You read the third-party's specification that explains their inputs and their expected results. How do you control the third-party environment for every possible scenario that can occur? This is especially difficult when certain results only occur intermittently such as certain times of the year. Even more difficult is how you test for failure scenarios. You can't cause the third-party system to fail but in case that system does fail you want to protect your users. You don't want your user's to have any of their data corrupted; you don't want your system to fail especially if it's a 24x7 system and must be up all the time; and you minimally want to inform your users that the system is not functioning properly due to the failure of an outside system.

One approach for testing third-party components is to create a proxy. All interactions with the outside system are done via an interface and communication with that system is done via an implementation of that interface. Now you are just testing the interface to make sure that you can handle all expected and unexpected results from that interface. When writing your test code you create a test implementation of that interface that mimics the true third-party implementation.  The reasoning behind this approach is that in the end as long as your program interacts correctly with the interface then all is well. This statement is not untrue. The problem with it is that you wind up writing code that is intended only for testing, but is now part of the whole system. It is more code that you have to maintain and it bloats your released application.