When developing systems of any size the development team inevitably encounters the following problem. The developers of one sub-system need access to functionality to be provided by another, but the second sub-system is not in a position to provide the functionality and probably will not be for some time. When this happens it is common for the sub-system teams to provide stubs.
Stubs come in several flavours:
- non-functional stubs provide no functionality, they simply provide a template interface to allow client sub-systems to compile;
- static-function stubs allow client sub-systems to compile and also provide static responses when the interface is called;
- dynamic stubs provide more complex responses when called. Methods used to provide these dynamic stubs vary but some common approaches are:
- record and playback,
- static tables,
- randomised response, and
- minimal function.
A stub is a proxy for the final functionality to be offered by the sub-system. As such we want the stub references in the client code to use the same calling convention as the final product. In the build process we need some means to nominate the stub or the final product into our build.
There are two principal approaches to solving this latter problem. The first relies on the build itself to select the appropriate module (stub or final). In our build script we may have, for example, a simple path modifier that builds either the stub or final code into a library which is then used by clients. The second method relies upon the source control system to deliver either the stub or final source into the source configuration, this source is then built into the target library. In this post I begin looking at some of the issues involved in both build and configuration managing stubs. Read the rest of this entry ?
