Teste de mutação em .NetStryker Mutator — Kill the mutantsVocê já se perguntou se os testes que você escreve são de fato eficientes?
Temos como conhecimento base que o código de nossa aplicação está “seguro” quando criamos testes que garantam a qualidade e previnam regressões.
Mas quem garante a qualidade dos testes?
Quem testa os testes?Essa é uma pergunta bem comum no cenário de qualidade, quando falamos de testes em aplicações.
É bem comum olharmos para a cobertura de código para mensurar a eficiência dos testes que criamos. Porém quantidade não significa qualidade!
Mutantes em ação!Os testes de mutação surgem nesse cenario provocando alterações, no seu código, com a finalidade de quebrar o teste que cobre o trecho em questão.
Se pelo menos uma (aqui é um pouco mais abrangente, falaremos melhor mais abaixo) dessas mutações causar a quebra do teste, ou seja fazer o teste falhar, consideramos que o código está de fato coberto.
Stryker .NetO Stryker vem com a proposta de ser uma ferramenta para testes de mutação, oferecendo uma configuração simples e integrada a relatórios muito intuitivos.
A versão para dotNet pode ser utilizada como uma ferramenta dotnet (dotnet tool), via CLI.
dotnet tool install -g dotnet-stryker
Talk is cheap… Show me the codeSe o conceito de testes mutantes ainda não ficou muito claro, acredito que com o demo a seguir algumas dúvidas devem ser respondidas.
No exemplo a seguir, eu criei um projeto Xamarin.Forms, com uma ViewModel que possui uma lógica de validação de máscara de CPF.
À partir da versão 1.2.0 o Stryker suporta projetos Xamarin.Forms para testes mutantes. 🎉🎉
https://medium.com/media/0ae6a5e6fcf7ca143971d2a046563f7e/hrefEm cima dessa lógica eu criei os testes de unidade abaixo:
https://medium.com/media/199debdf9acf4a9c209bade3e13ae617/hrefApós isso fiz algumas configurações para os testes mutantes através de um arquivo stryker-config.json
https://medium.com/media/4a3adfffc05c5d7ab714addeec9e535e/hrefAqui eu basicamente configurei o nível das mutações pro mais avançado disponível pela ferramenta, quais relatórios eu quero gerar e os “limites” de percentuais para considerar um código de fato coberto.
Entenda:
Executando o stryker .netDepois de ter instalado a ferramenta stryker, eu rodei ela no diretório onde fica o projeto de testes.
Resultado de 10 mutantes mortosCom isso obtivemos o resultado de 10 mutantes “mortos”, ou seja, que quebraram meus testes de unidade ao alterar a lógica da minha ViewModel.
É uma boa pontuação! De 12 mutantes 10 foram mortos nessa execução.
No relatório HTML podemos ver com mais detalhes qual foi a atuação do Striker no nosso código:
Stryker Report DashboardAqui no dashboard podemos ver que foram criados 13 mutantes ao total, para a MyViewModel, mas um deles não estava coberto (provavelmente uma das condições if/else).
Atingimos então o score de 76.92, assim ficamos na marca do Low que definimos no nosso arquivo de configuração.
Se clicarmos no nome do arquivo, temos mais detalhes sobre a mutação que aconteceu naquele código:
MyViewModel.cs Stryker .NetAqui podemos ver que foram aplicadas algumas mutações em cima do meu regex e muitas delas quebraram meus testes.
MyViewModel.cs Stryker .NetPor fim, temos aqui a condição onde foi criado uma mutação mas os nossos testes não cobrem, pois em nenhum teste eu envio um input nulo/vazio.
E ai? Curtiu a ferramenta?
O Striker também possuí uma extensão para adicionar o dashboard, do relatório HML, em uma aba no AzureDevops. Confere lá na doc como configurar.
Stryker AzureDevops extensionVocê encontra o exemplo desse artigo no meu github:
GitHub - felipebaltazar/XamarinStrykerSample: Stryker .net sample application
Referências: Oque são testes de mutação por Paulo Gonçalves * Documentação do Stryker .Net * Repositório do código do Stryker .net * Hugo van Rijswijk — Who is testing your tests?*