Stubs and drivers. Two facilitators of testing your software, two words commonly used in IT projects all around, two objects which lead to lots of discussion, confusion, frustration and broken dreams. This post will be about my own experiences of good use and misuse of stubs and drivers, it should help to clear up some of the confusion and help you with proper use. This will be part 1 of my rant on stubs and drivers used for software testing.
The modern IT landscape has changed in the last decade. Where companies were focusing on automating their own processes in the previous century, the new century brought new knowledge, methodologies and tools to extend the automation over the boundaries of the company or company division. The internet expanded rapidly, this combined with new techniques and insights made it easy for software to connect to other software, anywhere in the world.
These new developments also created new challenges, and off course new problems. One of these problems is the sudden dependencies that exist between companies, between company divisions or between a company and 3rd party suppliers. These dependencies required a new focus on software testing, hence the (re)birth of chain testing. If you’ve never heard of chain testing or are eager to learn more, get your hands on a copy of the complexity of chaintesting. Chain testing will help you to validate if the chain your software is part of will function correctly and supports the processes it was designed to support correctly. One of the big challenges with chain testing is organizing a test environment which has all the connections needed to test the entire chain. Because of the complexity of such chains and the challenges you need to overcome regarding connectivity, test data, etc. not all connections will be available in all of your test environments. It is common practice a development or test environment will not communicate directly to third parties. This brings me to the essence of this post. How will you test your software if it has external dependencies? You can do so by using stubs and drivers.
First definitions:
A driver is a piece of software acts as a enabler of the software under test. It allows you to past test cases to your test object. Eg. a dummy website that invokes a web service. The web service is your test object. But also test frameworks or testing applications can be seen as drivers.
A stub is a piece of software replacing a (for the testobject) external system, thus removing the dependency of this system.
I realize that these definitions are probably not waterproof, especially if they are used in a unit test environment. But for system and integration testing, where the test object is not a method, or a class, but a component or complete parts of systems, these definitions will suffice.
Why are stubs and drivers needed? The answer is quite simple: to reduce dependencies. If I am responsible for realizing a piece of software that communicates with other software I don’t want my project to be dependant of other projects. For example, if my job is to create a service that calculates the price of an insurance, I should not wait testing this service until another party realized a front end application using this service. This is where my driver comes in, replacing the front end, and enabling me to test my service. Same the other way around, if I was responsible for realizing the front end of the application, I do not want the progress of my project to depend on the progress of the service that is being build. Here the stub comes along. Instead of relying on the service, I can test the website without any problems like availability of the services, data from the service and unexpected exceptions thrown by the service. Off course testing these objects without testing the actual connection between the objects poses a risk. But as it is with all risks you get a choice if you need to test these connections in a integration test or chain test, or if you accept the risk and can do without.
So far for the introduction on stubs and drivers.
Stay tuned for the next part.
