Module Testing and Buddy Testing

I am working on a project that lists and briefly desribes 40 fundamental topics every software tester at Microsoft should know. One of them is module testing.

Module testing is arguably the most fundamental type of software testing. Most non-trivial software systems are composed of basic building blocks such as DLLs (dynamic link libraries) and .NET assemblies in a Windows environment, SOs (shared object files) in a Unix-like environment, and Java packages. The idea is simple: if the basic building blocks which make up a software system are not correct, then the software system as a whole cannot possibly be correct. In a Windows development environment the most common scenario is that developers create a library composed of one of more classes which in turn contain one or more methods which must be tested. When developers use native Win32 code (typically with the C++) language the result is a usually file with a .dll extension. Native code often, but not always, uses COM technology so that the module library can be called from multiple languages such as C++, C#, and JavaScript. When developers use managed .NET code (typically with the C# or VB.NET language) the result is also usually a file with a .dll extension although the internal structure is entirely different from a native code DLL file. Managed code libraries do not use COM technology — in fact one of the motivations for creating the .NET environment was to reduce the need for programming with the very difficult to use COM.

Here’s a simplified example. Suppose a developer is part of a team working on a software system which performs some mathematical calculations including the harmonic mean of two numbers. (The arithmetic mean is a normal average; the harmonic mean is an average used when the data points are rates such as speed measured in miles per hour). The developer uses C++ to create a COM based, dual interface library named MyMathLib.dll which contains a class named MyMathFunctions which in turn contains a method HarmonicMean(). At this point the devloper could check the new C++ source code into a source code repository where it would eventually be compiled, perhaps by a build team, and the HarmonicMean() method would be available for other developers to use in the software system and for testers to test. An alternative approach is for the developer to request a buddy test. Here the developer would not check the library source code into the source code repository. Instead the developer would compile the source and then give the resulting DLL to a test engineer. The test engineer would then test the methods in the DLL. For example, if using JavaScript, the tester would copy the DLL to a test host machine. Then the tester would register the DLL on the test host using the regsvr32.exe tool and create a small JavaScript test harness that tests the method in the DLL along the lines of:

WScript.Echo("Begin test\n");
var obj = new ActiveXObject("MyMathLib.MyMathFunctions");
var actualResult = obj.HarmonicMean(30,60);
var expectedResult = 40;
if (actualResult == expectedResult)

One of the ideas of buddy testing is to have some measure of confidence that new source code is relatively free of bugs before the code is checked into a source code repository.


This entry was posted in Software Test Automation. Bookmark the permalink.