Unit Testing in C++ with Compiler Instrumentation and Friends

Abstract

In C++, test code is often interwoven with the unit we want to test. During the test development process we often have to modify the public interface of a class to replace existing dependencies; e.g. a supplementary setter or constructor function is added for dependency injection. In many cases, extra template parameters are used for the same purpose. All existing solutions have serious detrimental effects on the code structure and sometimes on the run-time performance as well. In this paper, we overview existing dependency replacement techniques of C++ and we evaluate their advantages and disadvantages. We introduce our non-intrusive, compiler instrumentation based testing approach that does not have such disadvantages. All non-intrusive testing methods (including our new method) require access to an object’s internal state in order to setup a test. Thus, to complement our new solution, we also present different approaches to conveniently access private members in C++. To evaluate these techniques, we created a proof-of-concept implementation which is publicly available for further testing.

Tools and Language Elements for Testing, Encapsulation and Controlling Abstraction in Large Scale C++ Projects

“…Compared to existing compile-time instrumentation solutions, our technique does not require the modification or even the recompilation of the intercepted functions, which is a possible advantage in case of legacy code, system libraries, third-party shared libraries or in situations when we have to avoid library interposing. We have created a prototype implementation using the LLVM/Clang compiler infrastructure, which is publicly available at [14].…”

“…These replacement functions behave as a proxy; they forward each function call on a given Turtle instance to a corresponding test double (lines [17][18][19][20][21][22]. The way we get the reference for a relevant test double is pretty simple in this test: we return a reference to a static instance of the MockTurtle class (lines [12][13][14][15]. We can use this simplification because we know that there is only one Turtle object over the lifetime of our test-case.…”

“…Next, we set up the architecture dependent function pointer adjustment (line 10). Then, we get the offset and return with the appropriate element in the vtable (lines [11][12]. We could replace virtual functions by exploiting this technique.…”

“…Values of this type may be pointers to any int data member of the class A. Once we get the pointer to the member in line 13, we can bind this pointer to an object, and this way, we get a reference to the data member (in line 14).…”

“…We bind the result of get() function to the object of the class, and then we return with a reference to the resulting member. Later, (in lines [13][14][15][16][17][18][19] we add another overload that handles the cases where the object is bound to a const lvalue reference. In this case, we would like to preserve the constness of the object, therefore we should return with a const reference to the member.…”