Principia: Power from Simplicity

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.

Although the second approach has some appeal, the first offers more flexibility. Suppose We have module A that is to supply some functionality to a client system S. The normal build chain would be something like A-Ao-L-S (source A built to object Ao which is linked into a library L¹ and consumed by system S).

If we supply a stub A’ the chain becomes A’-Ao’-L-S.

The L-S relationship remains the same whether we elect to build the stub or final product into system S. So far, so good. Our build system simply nominates the appropriate build into library L (A’-Ao’ or A-Ao). This allows us to build the entire system with or without the stub code in place.

Suppose the problem where a little more complex. Suppose that instead of L being used universally in S there were an intermediate set of sub-systems (S’ and S”). Now our build chain is: A-Ao-L-(S’|S”)-S

What if developers of S’ wish to use the stub code and S” wish to use the final code for testing? The build system that nominates Ao or Ao’ into L is not sufficient to accommodate this requirement. We need to add another step and provide a means to nominate the appropriate library.

But this opens up another problem. The libraries L and L’ currently contain either stub code or final code, but the sub-systems S’ and S” may each require different component to be stubbed out at different times and this will lead to a profusion of libraries, each with a unique combination of stubbed modules.

One we reach this situation we need to query our library architecture and our testing approach. There is no universal approach to building systems using arbitrary set of stubs like this. We could use some run-time configuration but this opens up a whole new set of issues around configuration management and ensuring delivered systems do not contain inappropriate stub code.

This post has offered a very light-weight introduction to build management of stubs. This is, of course, a large a complex issue for configuration management. The take-home message should be, make sure you design your build system with stubbing in mind and work with system architects, test managers and developers to ensure that your build system can accommodate appropriate configurations for stubbed testing.

---

. Although identified as a library, L could be any collection of items representing stubbed or non-stubbed entities.