Refactoring for testability in C++
 

In this webinar, we are going to talk about hard-to-test patterns in C++ and show how to refactor them. The difficulty, in this context, does not lie in the code's inherent complexity. 

​

For example, software that has many branches or tries to solve a problem that needs to follow a set of convoluted business rules will not be examined. In fact, all of the examples are rather simple. 

The focus will be on patterns technically difficult to unit test because they may

• Require irrelevant software to be tested too  
          E.g.: 3rd party libraries, classes other than the one under test

• Delay the test execution
          E.g.: sleeps inside code under test

• Require intricate structures to be copied or written from scratch
          E.g.: fakes containing a lot of logic

• Require test details to be included in the production code
          E.g.: #ifdef UNIT_TESTS<br>

• Make changes and/or are dependent on the runtime environment
          E.g.: Creating or reading from files 

You should author testable code that can be verified with small and atomic tests. You should not have to test unrelated logic nor implement complex functionality just to be able to test. After all, unit testing should be fun and give you the quick feedback you need to confidently develop without worrying you "broke" something. 

With the introduction of more feature-rich testing frameworks, dependency injection containers etc, there may be ways to get around the inherent lack of testability of these examples. That being said, it is good to know how to refactor them according to object-oriented design best practices as well as the C++ Core guidelines. We illustrate this by relying only on the well-adopted [GoogleTest] framework.

To comfortably attend this seminar you will need to be familiar with

• C++

• Object Oriented Design

• Unit testing and mocking