Analysis and validation of test case redundancy in testing suites of Java libraries

Abstract

When studying the test suites from some Java libraries, it is possible to observe a certain redundancy in the execution paths that some of the test cases take, whose reason is not known. In order to understand this issue, we establish two hypotheses: one that this redundancy happens due to the suite being an automatically generated suite, and one that it comes from test cases that test inputs of different natures, such as empty strings or null strings. To validate these hypotheses, we perform a detailed study by analysing the behavior of the test cases and the associated application code. We consider a code coverage criterion, computed by generating the test path of each test case in the suite and comparing these with the prime path coverage of the tested methods. For this procedure we first adapted a coverage analysis tool that considers the prime path coverage criterion, and afterwards we collected additional data about the application code and the test suite in order to understand the rationale behind the tests. Finally, a manual analysis is made in the source code of the methods being tested and their respective test cases. Results show that the projects’ suites are closer to a developer-implemented suite, and not a generated one. It also shows that, when studying the tests with redundant test paths, most consist of cases that test different types of input - our second hypothesis. There are some cases that do not have a clear purpose and test very similar inputs, with some being even duplicated, but this occurs in a considerably insignificant scale.

Ao estudar suítes de testes de algumas bibliotecas Java, é possível perceber uma certa redundância no caminho que alguns dos casos de teste tomam, cuja razão é desconhecida. A fim de entender este problema, estabelecemos duas hipóteses: uma de que esta redundância acontece devido à suíte ser automaticamente gerada utilizando uma ferramenta de geração automática de testes, e uma de que ela se origina em casos de teste que testam parâmetros de entrada de naturezas diferentes, como palavra vazia e palavra nula. Para validar estas hipóteses, fazemos um estudo detalhado, analisando o comportamento dos casos de teste associado ao código da aplicação. Levamos em consideração um critério de cobertura de código, computado gerando o caminho de execução de cada caso de teste presente na suíte e comparando estes com a cobertura de caminhos primos do método. Para este procedimento primeiro adaptamos uma ferramenta de análise de cobertura que considera o critério de caminhos primos, e posteriormente coletamos dados adicionais acerca do código da aplicação e da suíte para entender os objetivos dos testes. Após isto, uma análise manual é feita no código dos métodos sendo testado e seus respectivos casos de teste. Resultados mostram que as suítes dos projetos são mais próximas de uma suíte implementada por desenvolvedores, e não de uma suíte gerada automaticamente. Também é mostrado que, ao analisar os testes com caminhos de execução redundantes, a maioria consiste de casos que testam diferentes tipos de parâmetros de entrada - nossa segunda hipótese. Existem alguns testes que não possuem propósito e alguns que testam valores de entrada semelhantes, sendo alguns inclusive duplicados, mas isto ocorre em uma escala consideravelmente insignificante.