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

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...

Full description

Bibliographic Details
Main Author: Böhlin, Per
Format: Others
Language:English
Published: Linköpings universitet, Institutionen för datavetenskap 2010
Subjects:
Online Access:http://urn.kb.se/resolve?urn=urn:nbn:se:liu:diva-59238
id ndltd-UPSALLA1-oai-DiVA.org-liu-59238
record_format oai_dc
spelling ndltd-UPSALLA1-oai-DiVA.org-liu-592382018-01-13T05:15:30ZOn Patterns for Refactoring Legacy C++ Code into a Testable State Using Inversion of ControlengBöhlin, PerLinköpings universitet, Institutionen för datavetenskap2010RefactoringSoftware DevelopmentCoding PracticesSoftware TestingInversion of ControlDependency InjectionTest Driven DevelopmentUnit TestingInversion of Control ContainersObject Oriented DesignSoftware EngineeringProgramvaruteknikAmending 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. Student thesisinfo:eu-repo/semantics/bachelorThesistexthttp://urn.kb.se/resolve?urn=urn:nbn:se:liu:diva-59238application/pdfinfo:eu-repo/semantics/openAccess
collection NDLTD
language English
format Others
sources NDLTD
topic Refactoring
Software Development
Coding Practices
Software Testing
Inversion of Control
Dependency Injection
Test Driven Development
Unit Testing
Inversion of Control Containers
Object Oriented Design
Software Engineering
Programvaruteknik
spellingShingle Refactoring
Software Development
Coding Practices
Software Testing
Inversion of Control
Dependency Injection
Test Driven Development
Unit Testing
Inversion of Control Containers
Object Oriented Design
Software Engineering
Programvaruteknik
Böhlin, Per
On Patterns for Refactoring Legacy C++ Code into a Testable State Using Inversion of Control
description 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.
author Böhlin, Per
author_facet Böhlin, Per
author_sort Böhlin, Per
title On Patterns for Refactoring Legacy C++ Code into a Testable State Using Inversion of Control
title_short On Patterns for Refactoring Legacy C++ Code into a Testable State Using Inversion of Control
title_full On Patterns for Refactoring Legacy C++ Code into a Testable State Using Inversion of Control
title_fullStr On Patterns for Refactoring Legacy C++ Code into a Testable State Using Inversion of Control
title_full_unstemmed On Patterns for Refactoring Legacy C++ Code into a Testable State Using Inversion of Control
title_sort on patterns for refactoring legacy c++ code into a testable state using inversion of control
publisher Linköpings universitet, Institutionen för datavetenskap
publishDate 2010
url http://urn.kb.se/resolve?urn=urn:nbn:se:liu:diva-59238
work_keys_str_mv AT bohlinper onpatternsforrefactoringlegacyccodeintoatestablestateusinginversionofcontrol
_version_ 1718608438068510720