Visual Basic —

Stubs and Drivers

An application is basically a collection of software units connected by flow-control statements. The best time to test each individual unit is immediately after it has been written, if for no other reason than it is fresh in your mind (and because if you don't do it now, you'll never have the time later). Of course, having a software unit that relies on a call to another unit is only testable if you either comment out the call or substitute a dummy implementation. This dummy is known as a stub. Conversely, if you are testing a unit that would normally be called by a higher-level unit, you can create a temporary calling routine, called a driver. Let's take a closer look at these concepts.

Stubs

A stub is a temporary replacement piece of code that takes the place of a unit that has yet to be written (or made available by another developer). The implementation of the stub can be simple or somewhat complex, as conditions require. For instance, either it can be hard-coded to return a set value, or it can perform any of the following:

  • Provide a validation of the input parameters.
  • Provide a realistic delay so as not to convey a false impression that your new application is lightning-fast.
  • Provide a quick-and-dirty implementation of the intended functionality of the unit that you are substituting. Be careful not to be too quick-and-dirty; otherwise, you'll waste valuable time debugging throwaway code.

A useful task that you can perform with a stub is to pass the input parameters into the debug window. In most cases, this will merely show you what you expect to see, but it will occasionally throw up a parameter value that you never expected. Although you would have (probably) found this out anyway, you will have immediately been given a visible sign that there is something wrong. While formalized testing is a good method of identifying bugs, so is the common sense observation process ("that can't be right…").

Drivers

These either contain or call the unit that you are testing, depending on the nature of the code. For a simple unit of code such as a calculation routine, a dedicated piece of test code in another module is sufficient to call the piece of code being tested and to check the result. The idea of using a driver is to provide a basic emulation of the calling environment to test the unit.

The advent of the ActiveX interface now means that it is possible to invoke a test container simply by creating a reference to your piece of code in a new instance of Visual Basic. This does, of course, mean that your code must be given a public declaration and so on, but this client/server-based approach truly leads to flexibility in your systems. And of course, if you are creating ActiveX documents, you can test your development only in a driver-style environment-for example, Microsoft Internet Explorer.