Por favor, use este identificador para citar o enlazar este ítem:
https://repositorio.ufpe.br/handle/123456789/44894
Comparte esta pagina
Registro completo de metadatos
Campo DC | Valor | Lengua/Idioma |
---|---|---|
dc.contributor.advisor | BORBA, Paulo Henrique Monteiro | - |
dc.contributor.author | SILVA, Léuson Mário Pedro da | - |
dc.date.accessioned | 2022-06-28T16:05:57Z | - |
dc.date.available | 2022-06-28T16:05:57Z | - |
dc.date.issued | 2022-02-24 | - |
dc.identifier.citation | SILVA, Léuson Mário Pedro da. Detecting, understanding, and resolving build and test conflicts. 2022. Tese (Doutorado em Ciência da Computação) - Universidade Federal de Pernambuco, Recife, 2022.- | pt_BR |
dc.identifier.uri | https://repositorio.ufpe.br/handle/123456789/44894 | - |
dc.description.abstract | During collaborative software development, developers usually adopt branching and merging practices when making their contributions, allowing them to contribute to a software project independently. Despite such benefits, branching and merging come at a cost — the need to merge software and to resolve merge conflicts, which often occur in practice. While modern merge techniques, such as 3-way or structured merge, can automatically resolve many such conflicts, they fail when conflicts arise at the semantic level, known as semantic conflicts. These conflicts are revealed by failures when building and testing integrated code, build and test conflicts, respectively. Detecting such semantic conflicts requires understanding the software’s behavior, which is beyond the capabilities of most existing merge and assistive tools. To address the need for better assistive tools, we investigate semantic conflict occurrence by finding their causes and proposing tools that could support developers when facing these conflicts during merge scenario integrations. Initially, we perform a study investigating the frequency, structure, and adopted resolution patterns of build conflicts by empirically analyzing 451 open-source Java projects. As a result, we provide a catalogue of conflicts with 239 occurrences spread into six categories. Most build conflicts are caused by missing declarations removed or renamed by one developer but referenced by someone else. Further, analyzing some of these conflicts, we also report a catalogue of resolution patterns. In order to evaluate the occurrence of test conflicts, we adopt a different approach as these conflicts involve the semantics of a program. Consequently, they can not be detected during the compilation phase of the build process. This way, initially, we perform a second study investigating their occurrence by exploring the automated creation of unit tests as partial specifications to detect conflicts. Relying on a ground-truth dataset of more than 80 mutually integrated changes’ pairs on class elements from 51 software merge scenarios, we manually analyzed them and investigated whether test conflicts exist. Next, we systematically explore the detection of conflicts through four unit-test generation tools, as also the adoption of Testability Transformations aiming to increase the testability of the code under analysis. As a result, we provide a catalogue of 28 test conflicts, of which 9 of them were detected by our approach. Our results show that the best approach to detect conflicts involves combining the tools Differential EvoSuite and EvoSuite applied with Testability Transformations. As a final contribution, we present SAM, a semantic merge tool based on unit test generation, which warns developers about prominent conflicts on ongoing merge scenario integration. Overall, our results bridge a gap in the literature regarding the occurrence of code integration semantic conflicts during software development. Based on each conflict type, we investigate their causes and options to deal with them. While build conflicts could be automatically detected and fixed by an automatic repair tool, test conflicts might be detected by a semantic merge tool based on unit test generation. | pt_BR |
dc.description.sponsorship | FACEPE | pt_BR |
dc.language.iso | eng | pt_BR |
dc.publisher | Universidade Federal de Pernambuco | pt_BR |
dc.rights | openAccess | pt_BR |
dc.rights | Attribution-NonCommercial-NoDerivs 3.0 Brazil | * |
dc.rights.uri | http://creativecommons.org/licenses/by-nc-nd/3.0/br/ | * |
dc.subject | Engenharia de software | pt_BR |
dc.subject | Integração de código | pt_BR |
dc.title | Detecting, understanding, and resolving build and test conflicts | pt_BR |
dc.type | doctoralThesis | pt_BR |
dc.contributor.advisor-co | BERGER, Thorsten | - |
dc.contributor.authorLattes | http://lattes.cnpq.br/8681457281512244 | pt_BR |
dc.publisher.initials | UFPE | pt_BR |
dc.publisher.country | Brasil | pt_BR |
dc.degree.level | doutorado | pt_BR |
dc.contributor.advisorLattes | http://lattes.cnpq.br/9395715443254344 | pt_BR |
dc.publisher.program | Programa de Pos Graduacao em Ciencia da Computacao | pt_BR |
dc.description.abstractx | Durante o desenvolvimento colaborativo de software, desenvolvedores adotam práticas de criação e integração de ramos de desenvolvimento quando trabalham em suas contribuições, permitindo que eles contribuam para um projeto de software independentemente. Apesar destes benefícios, estas práticas vem com um custo, a necessidade de integrar software e resolver conflitos de merge. Enquanto técnicas modernas de merge podem resolver automaticamente muitos destes conflitos, elas falham quando o conflito surge no nível semântico conhecidos como conflitos semânticos. Estes conflitos são revelados por falhas durante o processo de build e execução de testes do código integrado conhecidos como conflitos de build e teste, respectivamente. Detectar estes conflitos semânticos requer um entendimento do comportamento do software, o que está além da capacidade da maioria das ferramentas assistentes e de integração de código. Dada a necessidade de melhores ferramentas assistentes, nós investigamos a ocorrência de conflitos semânticos identificando suas causas e propondo ferramentas que possam apoiar os desenvolvedores. Inicialmente, nós realizamos um estudo identificando a frequência, estrutura e padrões de resolução adotados em conflitos de build analisando empiricamente 451 projetos Java open-source. Como resultado, nós provemos um catálogo de conflitos com 239 ocorrências divididos em seis categorias. A maioria dos conflitos de build são causados por declarações não-resolvidas, removidas ou renomeadas por um desenvolvedor mas referenciadas por outra pessoa. Além disso, analisando alguns destes conflitos, nós também reportamos um catálogo de padrões de resolução. Para avaliar a ocorrência de conflitos de teste, nós adotamos uma abordagem diferente, pois estes conflitos envolvem a semântica de um programa. Consequentemente, eles não podem ser detectados durante a fase de compilação do processo de build. Desta forma, nós realizamos um segundo estudo investigando sua ocorrência, explorando a criação automática de testes unitários como especificações parciais para detectar conflitos. Baseando-se em um conjunto de mais de 80 mudanças mútuas em elementos de classes de 51 cenários de merge com ground-truth, nós analisamos e investigamos se conflitos de teste existiam. Em seguida, nós exploramos sistematicamente a detecção de conflitos por meio de ferramentas de geração de testes, como também a adoção de Transformações de Testabilidade visando aumentar a testabilidade do código em análise. Como resultado, nós apresentamos um catálogo de 28 conflitos de testes, dos quais 9 foram detectados por nossa abordagem. Nossos resultados mostram que a melhor abordagem para detectar conflitos envolve a combinação das ferramentas Differential EvoSuite e EvoSuite aplicadas com Transformações de Testabilidade. Como contribuição final, nós apresentamos SAM, uma ferramenta de merge semântica baseada na geração de testes unitários, que avisa desenvolvedores sobre conflitos em cenários de merge em andamento. No geral, nossos resultados se atentam a uma lacuna na literatura sobre a ocorrência de conflitos de integração de código semânticos durante o desenvolvimento de software. Baseado no tipo de conflito, nós investigamos suas causas e opções para lidar com eles. Enquanto conflitos de build podem ser detectados e solucionados por uma ferramenta de reparo automático, conflitos de teste poderiam ser detectados por uma ferramenta de merge semântica baseada na geração de testes unitários. | pt_BR |
Aparece en las colecciones: | Teses de Doutorado - Ciência da Computação |
Ficheros en este ítem:
Fichero | Descripción | Tamaño | Formato | |
---|---|---|---|---|
TESE Léuson Mário Pedro da Silva.pdf | 2,84 MB | Adobe PDF | ![]() Visualizar/Abrir |
Este ítem está protegido por copyright original |
Este ítem está sujeto a una licencia Creative Commons Licencia Creative Commons