Tal como tinha mencionado previamente, vou começar a usar os issues para fazer um log dos problemas. Tenciono usar esta informação como um resumo do estado corrente do meu progresso. Naturalmente, irei atualizando o log com o decorrer do tempo. Desta forma, o professor poderá ir tendo uma ideia do que está a acontecer no background.
1- Test Code Duplication:
Continuo sem conseguir implementar o "Test Code Duplication" smell.
Tentei implementar a versão alternativa que estava convicto de que devia de funcionar (criar um if para cada tipo de statement), mas o código ficou demasiado complexo. Por exemplo, caso o statement seja um método, é necessário: (1) averiguar que o statement corresponde a uma instância de um método; (2) obter o nome do método que está a ser chamado; (3) obter o nome das respetivas variáveis (tem de ser obtido à parte do nome do método). Ainda mais, depois de todo este processo, obtém-se uma String só com o nome do método e uma String com o nome dos argumentos (separados por vírgulas), sendo ainda necessário juntar as 2 Strings para poderem ser colocadas num set. Tem-se todo este trabalho só para fazer algo que já será tratado no pós-processamento... A ideia era minimizar o número de linhas repetidas com secondary criterion para alivar o trabalho que seria feito mais tarde no pós-processamento, mas, claramente, esta não é a forma correta de o fazer.
Sendo que as linhas repetidas são eliminadas no pós-processamento, decidi analisar a classe "TestCaseMinimizer". Pelo que entendi, no pós-processamento, apenas se remove uma linha de cada vez e vê-se se o teste mantem (ou não) o comportamento inicial. Isto não se aplica no secondary criterion.
Claro, pode-se sempre alterar outras partes do código, mas é difícil prever o impacto que isso pode ter a longo prazo. O ideal seria fazer com que um statement guardasse sempre o nome de uma variável (teria valor null caso não fosse declarada uma nova variável) e o respetivo valor. Talvez seja uma alteração muito brusca... Para minimizar o impacto, acho que se poderia alterar só a classe "TestCodeVisitor". Dada a abordagem que tenho agora, a classe já tem de ser chamada para criar as Strings de cada statement.
Observe-se o seguinte exemplo:
Este é o método "visitMethodStatement" da classe "TestCodeVisitor" que já está a obter o nome do método e o nome das variáveis! O trabalho já está feito! Será apenas uma questão de guardar a informação numa nova variável global.
----- Atualização 5 de dezembro -----
2 - Slow Tests:
Já está implementado! As classes "MultiCriteriaManager" e "BranchesManager" têm um método "calculateFitness" que recebe um TestChromosome c. Tem-se que "TestCase test = c.getTestCase();". É feito "runTest(test)", sendo possível colocar um timer antes e depois desta linha. A duração corresponde à diferença entre os 2 timers.
Decidi guardar a duração dentro da classe "TestChromosome". A duração é uma variável global inicializada a -1. Também foi necessário criar um getter e um setter.
Sendo que cada unidade de tempo adicional incrementa o valor de smellCount, achei que o mais razoável era considerar a duração em segundos.
É necessário ter um certo cuidado com esta abordagem: fazer debug pode levar os timers a ter valores irregulares!
3 - Empty Test:
Ainda não sei se vou usar este smell. De qualquer forma, já implementei classe EmptyTest. O método que calcula o respetivo smellCount só faz uma coisa:
return chromosome.getTestCase().size() == 0 ? 10000 : 0;
Assumindo que isto é algo que pode acontecer, ter um teste vazio é a pior coisa possível porque não tem qualquer potencial para evoluir! Assim sendo, se fosse apenas retornado 1, é natural que os outros testes com algum conteúdo fossem ter um smellCount superior: era só necessário terem pelo menos 2 linhas de código que, imediatamente, o smellCount seria superior a 1! O professor mencionou que não era boa ideia atribuir maiores/menores pesos a certos smells porque depois seria necessário justificar essas decisões, mas eu acho que esta pode ser uma exceção. Só terei de explicar no relatório o que acabei de escrever aqui.
Tal como tinha mencionado previamente, vou começar a usar os issues para fazer um log dos problemas. Tenciono usar esta informação como um resumo do estado corrente do meu progresso. Naturalmente, irei atualizando o log com o decorrer do tempo. Desta forma, o professor poderá ir tendo uma ideia do que está a acontecer no background.
1- Test Code Duplication:
Continuo sem conseguir implementar o "Test Code Duplication" smell.
Tentei implementar a versão alternativa que estava convicto de que devia de funcionar (criar um if para cada tipo de statement), mas o código ficou demasiado complexo. Por exemplo, caso o statement seja um método, é necessário: (1) averiguar que o statement corresponde a uma instância de um método; (2) obter o nome do método que está a ser chamado; (3) obter o nome das respetivas variáveis (tem de ser obtido à parte do nome do método). Ainda mais, depois de todo este processo, obtém-se uma String só com o nome do método e uma String com o nome dos argumentos (separados por vírgulas), sendo ainda necessário juntar as 2 Strings para poderem ser colocadas num set. Tem-se todo este trabalho só para fazer algo que já será tratado no pós-processamento... A ideia era minimizar o número de linhas repetidas com secondary criterion para alivar o trabalho que seria feito mais tarde no pós-processamento, mas, claramente, esta não é a forma correta de o fazer.
Sendo que as linhas repetidas são eliminadas no pós-processamento, decidi analisar a classe "TestCaseMinimizer". Pelo que entendi, no pós-processamento, apenas se remove uma linha de cada vez e vê-se se o teste mantem (ou não) o comportamento inicial. Isto não se aplica no secondary criterion.
Claro, pode-se sempre alterar outras partes do código, mas é difícil prever o impacto que isso pode ter a longo prazo. O ideal seria fazer com que um statement guardasse sempre o nome de uma variável (teria valor null caso não fosse declarada uma nova variável) e o respetivo valor. Talvez seja uma alteração muito brusca... Para minimizar o impacto, acho que se poderia alterar só a classe "TestCodeVisitor". Dada a abordagem que tenho agora, a classe já tem de ser chamada para criar as Strings de cada statement.
Observe-se o seguinte exemplo:
Este é o método "visitMethodStatement" da classe "TestCodeVisitor" que já está a obter o nome do método e o nome das variáveis! O trabalho já está feito! Será apenas uma questão de guardar a informação numa nova variável global.
----- Atualização 5 de dezembro -----
2 - Slow Tests:
Já está implementado! As classes "MultiCriteriaManager" e "BranchesManager" têm um método "calculateFitness" que recebe um TestChromosome c. Tem-se que "TestCase test = c.getTestCase();". É feito "runTest(test)", sendo possível colocar um timer antes e depois desta linha. A duração corresponde à diferença entre os 2 timers.
Decidi guardar a duração dentro da classe "TestChromosome". A duração é uma variável global inicializada a -1. Também foi necessário criar um getter e um setter.
Sendo que cada unidade de tempo adicional incrementa o valor de smellCount, achei que o mais razoável era considerar a duração em segundos.
É necessário ter um certo cuidado com esta abordagem: fazer debug pode levar os timers a ter valores irregulares!
3 - Empty Test:
Ainda não sei se vou usar este smell. De qualquer forma, já implementei classe EmptyTest. O método que calcula o respetivo smellCount só faz uma coisa:
return chromosome.getTestCase().size() == 0 ? 10000 : 0;Assumindo que isto é algo que pode acontecer, ter um teste vazio é a pior coisa possível porque não tem qualquer potencial para evoluir! Assim sendo, se fosse apenas retornado 1, é natural que os outros testes com algum conteúdo fossem ter um smellCount superior: era só necessário terem pelo menos 2 linhas de código que, imediatamente, o smellCount seria superior a 1! O professor mencionou que não era boa ideia atribuir maiores/menores pesos a certos smells porque depois seria necessário justificar essas decisões, mas eu acho que esta pode ser uma exceção. Só terei de explicar no relatório o que acabei de escrever aqui.