Mocking Frameworks considered harmful (especially in C++)

Software development without test automation can no longer be considered professional. Testing existing code requires test stubs. Employing Mocking Frameworks to replace dependencies is popular, but can lead to less-than-optimal designs, because dependencies between components no longer hurt as much when writing test cases. Especially in the context of C++ - lacking reflection capabilities - mocking frameworks tend to rely on unsafe mechanisms and obfuscated test case code. This talk demonstrates the liabilities and shows an alternative for C++.

Target Audience: Developers, Architects
Prerequisites: development experience, basic C++ knowledge
Level: Introductory

Extended Abstract
Software development without test automation can no longer be considered professional. However, you might have existing code bases or want to rely on external libraries that may make writing effective and fast unit tests hard or even near to impossible. A typical work-around for these situations is to introduce test stubs for such external dependencies to make your code testable.
Some propose to use mocking frameworks, such as GoogleMock, together with unit testing frameworks to ease the specification of the replacement objects. These mocking frameworks often come with their own domain-specific language (DSL) to describe the behavior and expected usage of the mock object. In addition to a learning curve, the DSLs often do not help much, when things do not work. The current lack of standardized reflection in addition requires macro trickery making fixing problems even harder. A second issue, is that existing code often must be prepared to suite the mocking frameworks interception mechanism to allow to inject the mock objects. Last but not least test-driven development (TDD) together with the use of a mocking framework can lead to high coupling, that TDD usually strives to reduce.