Submitted by Maria Medeiros (maria.dilva1@ufcg.edu.br) on 2018-06-05T13:58:29Z No. of bitstreams: 1 MELINA MONGIOVI CUNHA LIMA SABINO - TESE (PPGCC) 2016.pdf: 4752189 bytes, checksum: e1034c42632a733df07a498a7eea6d0b (MD5) / Made available in DSpace on 2018-06-05T13:58:29Z (GMT). No. of bitstreams: 1 MELINA MONGIOVI CUNHA LIMA SABINO - TESE (PPGCC) 2016.pdf: 4752189 bytes, checksum: e1034c42632a733df07a498a7eea6d0b (MD5) Previous issue date: 2016 / Capes / Definir e implementar refatoramentos não é uma tarefa trivial, pois é difícil definir todas as pré-condições necessárias para garantir que a transformação preserve o comportamento observável do programa. Com isso, ferramentas de refatoramentos podem ter condições muito fracas, condições muito fortes e podem aplicar transformações que não seguem a definição do refatoramento. Na prática, desenvolvedores escrevem casos de testes para checar suas implementações de refatoramentos e se preocupam em evitar esses tipos de bugs, pois 84% das asserções de testes do Eclipse e JRRT testam as ferramentas com relação aos bugs citados anteriormente. No entanto, as ferramentas ainda possuem esses bugs. Existem algumas técnicas automáticas para testar ferramentas de refatoramentos, mas elas podem ter limitações relacionadas com tipos de bugs que podem ser detectados, geração de entradas de testes, automação e performance. Este trabalho propõe uma técnica para escalar testes de ferramentas de refatoramentos. A técnica contém DOLLY um gerador automático de programas Java e C, no qual foram adicionadas mais construções de Java (classes e métodos abstratos e interface) e uma estratégia de pular algumas entradas de testes com o propósito de reduzir o tempo de testar as implementações de refatoramentos. Foi proposto um conjunto de oráculos para avaliar a corretude das transformações, dentre eles SAFEREFACTORIMPACT que identifica falhas relacionadas com mudanças comportamentais. SAFEREFACTORIMPACT gera testes apenas para os métodos impactados pela transformação. Além disso, foi proposto um novo oráculo para identificar transformações que não seguem a definição do refatoramento e uma nova técnica para identificar condições muito fortes. A técnica proposta foi avaliada em 28 implementações de refatoramentos de Java (Eclipse e JRRT) e C (Eclipse) e detectou 119 bugs relacionados com erros de compilação, mudanças comportamentais, condições muito fortes, e transformações que não seguem a definição do refatoramento. Usando pulos de 10 e 25 no gerador de programas, a técnica reduziu em 90% e 96% o tempo para testar as implementações de refatoramentos, enquanto deixou de detectar apenas 3% e 6% dos bugs, respectivamente. Além disso, detectou a primeira falha geralmente em alguns segundos. Por fim, com o objetivo de avaliar a técnica proposta com outras entradas de testes, foram avaliadas implementações do Eclipse e JRRT usando os programas de entrada das suas coleções de testes. Neste estudo, nossa técnica detectou mais 31 bugs não detectados pelos desenvolvedores das ferramentas. / Defining and implementing refactorings is a nontrivial task since it is difficult to define preconditions to guarantee that the transformation preserves the program behavior. There fore, refactoring engines may have overly weak preconditions, overly strong preconditions, and transformation issues related to the refactoring definition. In practice, developers manually write test cases to check their refactoring implementations. We find that 84% of the test suites of Eclipse and JRRT are concerned with identifying these kinds of bugs. However, bugs are still present. Researchers have proposed a number of techniques for testing refactoring engines. Nevertheless, they may have limitations related to the bug type, program generation, time consumption, and number of refactoring engines necessary to evaluate the implementations. In this work, we propose a technique to scale testing of refactoring engines by extending a previous technique. It automatically generates programs as test inputs using Dolly, a Java and C program generator. We add more Java constructs in DOLLY, such abstract classes and methods and interface, and a skip parameter to reduce the time to test the refactoring implementations by skipping some consecutive test inputs. Our technique uses SAFEREFACTORIMPACT to identify failures related to behavioral changes. It generates test cases only for the methods impacted by a transformation. Also, we propose a new oracle to evaluate whether refactoring preconditions are overly strong by disabling a subset of them. Finally, we present a technique to identify transformation issues related to the refactoring definition. We evaluate our technique in 28 refactoring implementations of Java (Eclipse and JRRT) and C (Eclipse) and find 119 bugs related to compilation errors, behavioral changes, overly strong preconditions, and transformation issues. The technique reduces the time in 90% and 96% using skips of 10 and 25 in Dolly while missing only 3% and 6% of the bugs, respectively. Additionally, it finds the first failure in general in a few seconds using skips. Finally, we evaluate our proposed technique by using other test inputs, such as the input programs of Eclipse and JRRT refactoring test suites. We find 31 bugs not detected by the developers.

Submitted by Johnny Rodrigues (johnnyrodrigues@ufcg.edu.br) on 2018-08-31T23:09:48Z No. of bitstreams: 1 GUSTAVO WAGNER DINIZ MENDES - DISSERTAÇÃO PPGCC 2014..pdf: 7175302 bytes, checksum: c99a663c85f93c308e26cc6d963f5d2e (MD5) / Made available in DSpace on 2018-08-31T23:09:48Z (GMT). No. of bitstreams: 1 GUSTAVO WAGNER DINIZ MENDES - DISSERTAÇÃO PPGCC 2014..pdf: 7175302 bytes, checksum: c99a663c85f93c308e26cc6d963f5d2e (MD5) Previous issue date: 2014-03-13 / Refatorar um programa é o ato de mudar sua estrutura visando melhorar algum aspecto arquitetural, sem que se mude seu comportamento observável. Desenvolvedores utilizam ferramentas como Eclipse e NetBeans para auxiliá-los no refatoramento de seus programas. Essas ferramentas implementam um conjunto de condições para garantir que as transformações realizadas não mudem o comportamento observável do programa. Porém, não é trivial identificar todas as condições necessárias para que um refatoramento seja correto devido à complexidade da semântica das linguagens e por não haver uma definição formal das linguagens e consequentemente dos refatoramentos. Os desenvolvedores de ferramentas de refatoramento costumam, por não haver uma definição formal, implementar os refatoramentos de acordo com seus conhecimentos da linguagem de programação. Na prática, desenvolvedores utilizam coleções de testes para avaliar a corretude de suas implementações. Entretanto, não existem evidências que os desenvolvedores utilizem um processo sistemático na definição dessas coleções. Neste trabalho, propomos uma técnica para testar implementações de refatoramentos de programas C. Ela consiste em cinco fases. Primeiramente, geramos automaticamente diversos programas C para serem refatorados a partir do CDOLLY, que foi proposto baseado em uma especificação em Alloy. Depois, geramos automaticamente uma coleção de testes de unidade dos programas via o CATESTER. Em seguida, aplicamos o refatoramento através do CREXECUTOR nos programas gerados utilizando a ferramenta a ser testada. Após isso, executamos a coleção de testes nos programas refatorados e, por fim, classificamos os erros de compilação e mudanças comportamentais identificados em bugs. Avaliamos a nossa técnica na implementação de oito refatoramentos do Eclipse CDT. Estes refatoramentos não só modificam a estrutura do programa, como também o corpo das funções, como o refatoramento Extract Function. Detectamos 41 bugs, que introduzem erros de compilação no programa resultante, e seis bugs relacionados a mudanças comportamentais. Replicamos manualmente os bugs encontrados em implementações de refatoramentos do NetBeans CND, Xrefactory e OpenRefactory e detectamos 29 bugs nessas ferramentas. / Refactoring a program is the act of changing its structure in order to improve any architectural aspect, without changing its observable behavior. Developers use tools like Eclipse and NetBeans to help refactoring their programs. These tools implement a set of conditions to ensure that the transformations performed do not change the observable behavior of the program. However, it is not easy to identify ali the necessary conditions for a refactoring to be correct due to the semantic complexity of the languages, mainly because the languages are not formally proved and neither the refactorings. In practice, developers often use collections of tests to assess the correctness of their implementations. However, there is no evidence of having systematic process in the definition of this collection. In this work, we propose a technique to test refactoring implementations of C programs. It consists of five phases. First, we generate automatically several C programs to be refactored from CDOLLY, which has been proposed based on a specification in Alloy. Then, we generate automatically a collection of unit tests of the programs via CATESTER. We then apply the refactoring through CREXECUTOR on the generated programs using the tool to be tested. After this, we execute the test collection in the refactored programs and finally we classify the compilation errors and behavioral changes in bugs. We evaluated our technique in the implementation of eight refactorings of Eclipse CDT. These refactorings not only modify the program structure, but also the body functions, such as the refactoring Extract Function. We detected 41 bugs, which introduce compilation errors in the resulting program, and six bugs related to behavioral changes. We analyzed manually these bugs in refactoring implementations of NetBeans, Xrefactory and OpenRefactory and identified 29 bugs in these tools.