On Patterns for Refactoring Legacy C++ Code into a Testable State Using Inversion of Control

Sammanfattning: Amending old projects of legacy code to include agile practices such as extensive unit testing and refactoring has proven difficult. Since automated unit testing was not widely used a decade ago, much code has been written without unit testing in mind. This is especially true for C++ where RAII has been the dominant pattern .This has resulted in a lot of code that suffers from what best can be described as low testability. This also strongly impedes the creation of new unit tests to already existing code. Due to the lack of unit tests, refactoring is done sparsely and with great reluctance. This thesis work tries to remedy that and, in the scope of a limited case study on an existing code base, looks into different ways of creating and utilizing object seams in legacy C++ code to decouple dependencies to make isolated testing possible. This regards to: What are the impediments for code to be testable in an isolated setting? What are the steps for refactoring code to a testable state? The results can be summarized as to contain a list of factors affecting testability, among them: the use of asserts, global state, object instantiation, work in constructor and breaking Law of Demeter. Further with regards to patterns for refactoring code to a testable state, two types of patterns have crystallized: the injection of dependencies and the masking of dependencies using various techniques. The effect these two base patterns have on breaking dependencies on the base level and the Meta level is outlined. A catalogue of patterns has been compiled as part of the appendix.   Inversion of Control (IoC) is a principle used to decoupling classes and since strong dependences is often an attribute giving grievances with regard to testability, it was a central concern in this thesis. IoC can be simplified from a developer standpoint with the help of frameworks or what is usually referred to as IoC containers. Two IoC containers for C++ were evaluated: Autumn Framework PocoCapsule In the evaluation of the two IoC containers it was concluded that Autumn was not mature enough as of the time of the evaluation to be used in production setting. PocoCapsule, even though compelling for some of its powerful features with regard to DSM and HOT, its configuration sometimes require in-code workarounds, affecting its usability in some set of scenarios. However, the big difference was with regard to how the two containers approaches configuration. PocoCapsule uses static analysis of its XML configuration file making it truly declarative while Autumn does runtime parsing and dynamic invocations resulting in a situation closer to procedural scripting.