Download article - Methods & Tools

Voodoo
A ‘Fake ’ object can be passed to the unit whereever the original class is used (implemented by
derivation, and without adding new members, to allow copy construction).
When a ‘Fake’ object is destroyed, the destruction event still goes through the expectation
engine, and is therefore appropriate when handing over the ownership of an object to the unit,
since it’s destruction is part of the unit’s behavior. If the unit does not own the object (e.g.,
receives it by reference), a second prefix, ‘FakeND ’ is more useful: the destruction event also
does not invoke the expectation engine.
Externals
Stubbing OS provided global function presents two new problems: First, the OpenCCore parser
(the C++ parser used by VoodooMock) can not handle OS level header files (which usually
contain compiler specific macros). But even worse, the include file hierarchy is never trivial
(e.g., ‘windows.h’ includes other files which actually define the system calls).
VoodooMock has a feature specifically designed for this case: provide an “alternative” header to
parse, and generate stubs according to. The fake header file then always includes the original,
and implements the stubs, in another names-pace, named ‘External’. For example, the
alternative header file for ‘windows.h’ might look like this:
HANDLE WINAPI CreateFileA(
__in LPCTSTR lpFileName,
__in DWORD dwDesiredAccess,
__in DWORD dwShareMode,
__in_opt LPSECURITY_ATTRIBUTES lpSecurityAttributes,
__in DWORD dwCreationDisposition,
__in DWORD dwFlagsAndAttributes,
__in_opt HANDLE hTemplateFile
);
BOOL WINAPI CloseHandle(
__in HANDLE hObject
);
And the real code must be modified, from using ‘CloseHandle(...)’, to
‘External::CloseHandle(...)’. Now the only thing that remains is to define ‘External’ as a macro
that expands to an empty string when compiling the real product.
Programmable Mock Objects
VoodooMock has a second implementation to every stubbed class, that allows complete
interception of all events into methods. This implementation is faster, and more suitable for
crunching tests. For more information, refer to the VoodooMock documentation.
Methodology
VoodooMock was design with the eXtreme Programming methodology in mind. This section
details how one XP team used it effectively.
Selecting a unit size is an art by itself. Experiment with different unit sizes, since there is no
single answer to the unit size issue. Making each class a unit provides excellent coverage with
ease, but will force testing wrapper and adapter classes, and will not cover integration between
classes.
Methods & Tools * Summer 2010 * Page 71