Build and test conflicts in the wild

• Ano de defesa: 2018
• Autor(a) principal: SILVA, Léuson Mário Pedro da
• Orientador(a): BORBA, Paulo Henrique Monteiro
• Tipo de documento: Dissertação
• Tipo de acesso: Acesso aberto
• Idioma: eng
• Instituição de defesa: Universidade Federal de Pernambuco
• Programa de Pós-Graduação: Programa de Pos Graduacao em Ciencia da Computacao
• País: Brasil
• Palavras-chave em Português: Engenharia de software; Conflitos de teste
• Link de acesso: https://repositorio.ufpe.br/handle/123456789/29991

Collaborative software development allows developers to simultaneously contribute to the same project performing different activities. Although this might increase development productivity, it also brings conflicts among developers contributions. Conflicts may arise in different development phases: during merging, when different contributions are integrated (merge conflicts); after integration, when building the integration results fail (build conflicts); or when testing, unexpected software behavior happens (test conflicts). To understand how different contributions from merge scenarios influence build and test conflicts occurrence, in this thesis we investigate the frequency, causes and adopted resolution patterns for these conflicts. We perform an empirical study evaluating merge scenarios from Java projects that use Travis CI for continuous integration and Maven as build manager. To identify conflicts, we access information from git repositories of the projects and their associated build process. Filters were applied to select merge commits that present unsuccessful build processes (caused by problems during the build creation or test execution), while their parent commits have successful build process. Besides parsing build logs for identifying the causes behind the broken builds, we also parse the source code to establish interference between contributions. Different from previous studies, we also evaluate scenarios that caused merge conflicts fixed by integrators, leading us to classify our results based on contributor and integrator changes to fix the conflicts. Although the number of build conflicts caused by contributor changes is high (66,4%), we have evidence that build conflicts can also be caused by changes performed after the integration by integrators (33,6%). The most recurrent causes of build conflicts concentrate on static semantic problems (80%), especially Unavailable Symbol (52,8% of all build conflicts that represents the attempt to use a symbol no longer available in the project). Test conflicts are caused by failed test cases, that are not restricted to old tests but also new or updated during the merge scenario. Additional analysis performed after tests execution can also cause test conflicts. Related to the adopted resolution patterns, build and test conflicts were fixed without returning to an old project version. Typically, parent commits authors are also responsible for fixing build and test conflicts. Our findings bring the evidence of build and test conflicts showing they occur independent of merge conflict occurrence during integration. For build conflicts, we define a catalog of causes that can be applied to assistive tools on software development aiming to avoid or treat such problems. For test conflicts, our scripts can be used to develop an assistive tool to developers when trying to understand the test case failure since we filter the parent’s contributions informing only those parts involved in the test failure.