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. The latter fact was described in Gerard Meszaros seminal work "XUnit Test Patterns" but as what often happens with the fine print or Pattern’s liabilities, ignored by many.
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.
Advertisement
