CppCon 2017

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.


This talk demonstrates "classical" mocking frameworks, shows the problems and demonstrates how Cevelop's Mockator approach can help refactoring existing code to get it under test and how a very simple plain C++ solution can be used instead of complicated mocking framework for unit tests with dependent code replaced by test stubs or mocks.

Outline:
* Introduction
** Fowler's Whisky Warehouse - classic example for Mocking Frameworks in C++
* Feathers' Seams: Dependency Injection
** Refactoring to Object Seams
** Refactoring to Template Seams
** Linker Seams
** Preprocessor Seams as a last resort
* Problem with "classic" Mocking Frameworks
* Simpler Mocking with Mockator
* Why and when you should not Mock

With a longer slot, more of the underlying test automation theory, based on xunitpatterns.com can be given.