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.

[pt] Contexto Injeção de Dependência (DI) é um mecanismo comumente aplicado para desacoplar classes de suas dependências com o objetivo de prover uma melhor modularização do software. No contexto de Java, a existência de uma especificação de DI e frameworks populares, como o Spring, facilitam o emprego de DI em projetos de software. Entretanto, más práticas de implementação de DI podem trazer más consequências, como maior acoplamento, dificultando alcançar o principal objetivo de DI. Apesar de a literatura sugerir a existência de anti-padrões de DI, não há uma documentação detalhada de tais más práticas. Em adição, não há evidência da ocorrência e da percepção de utilidade dos mesmos do ponto de vista de desenvovedores. Objetivos Nosso objetivo é revisar os anti-padrões de DI reportados com o objetivo de analisar sua completude e propor um novo catálogo de anti-padrões de DI para Java. Método Nós propomos um catálogo contendo 12 anti-padrões de DI para Java. Nós selecionamos 4 projetos open-source e 2 projetos closed-source que adotam um framework de DI e desenvolvemos uma ferramenta que analisa estaticamente a ocorrência dos anti-padrões de DI candidatos no código fonte das aplicações. Em adição, nós conduzimos uma pesquisa por meio de entrevistas face a face com três desenvolvedores experientes que regularmente aplicam DI em seus projetos. Nós estendemos a pesquisa com o objetivo de obter a percepção de um conjunto de 15 desenvolvedores experientes e novatos por meio de um questionário online Resultados Ao menos 9 anti-padrões de DI apareceram frequentemente nos projetos de software analisados. Em adição, a avaliação recebida dos desenvolvedores confirmaram a relevância do catálogo. Por fim, os respondentes expressaram o desejo de refatorar as instâncias de antipadrões de DI propostas. Conclusões O catálogo contém anti-padrões de DI que ocorrem na prática e são úteis. Compartilhar com praticantes da indústria os permitirá evitar a introdução de anti-padrões em seus projetos de software. / [en] Background Dependency Injection (DI) is a commonly applied mechanism to decouple classes from their dependencies in order to provide better modularization of software. In the context of Java, the availability of a DI specification and popular frameworks, such as Spring, facilitate DI usage in software projects. However, bad DI implementation practices can have negative consequences, such as increasing coupling, hindering the achievement of DI s main goal. Even though the literature suggests the existence of DI anti-patterns, there is no detailed documentation of such bad practices. Moreover, there is no evidence on their occurrence and perceived usefulness from the developer s point of view. Aims Our goal is to review the reported DI anti-patterns in order to analyze their completeness and to propose and evaluate a novel catalog of Java DI anti-patterns. Method We propose a catalog containing 12 Java DI anti-patterns. We selected 4 opensource and 2 closed-source software projects that adopt a DI framework and developed a tool to statically analyze the occurrence of the candidate DI anti-patterns within their source code. Also, we conducted a survey through face to face interviews with three experienced developers that regularly apply DI. We extended the survey in order to gather the perception of a set of 15 expert and novice developers through an online questionnaire. Results At least 9 different DI anti-patterns appeared frequently in the analyzed projects. In addition, the feedback received from the developers confirmed the relevance of the catalog. Besides, the respondents expressed their willingness to refactor instances of anti-patterns from source code. Conclusions The catalog contains Java DI anti-patterns that occur in practice and are useful. Sharing it with practitioners may help them to avoid such anti-patterns.