O artigo é baseado em uma postagem no canal de telegramas Cross Join .
Antes de falar sobre essa abordagem, primeiro explicarei em poucas palavras o que é o teste de mutação em geral. Para quem não sabe.
Teste de mutação
Quando você escreve testes, TDD ou não, mesmo com uma cobertura formal de 100%, você nunca terá certeza de que tudo foi realmente testado no código. Por exemplo, é possível cometer um erro piegas ao chamar assert no próprio teste.
assertEquals($a, $a);
E se mesmo durante o teste foi possível chegar a algum se, não é um fato que todas as condições neste se foram verificadas corretamente.
Para ter certeza de que os testes estão realmente testando, existe uma maneira: introduzir bugs no código você mesmo e ver se os testes caem fora disso. Se os testes ainda estiverem verdes com um bug óbvio, então nem tudo foi testado.
Por exemplo, você alterou o sinal de mais para menos ou adicionou "não" à condição e viu se os testes reagiram. Essa abordagem é chamada de "Teste de mutação".
Isso geralmente é feito em áreas muito críticas da programação, onde erros geralmente não são permitidos. Por exemplo, software rover ou software médico.
Claro, na construção do rover, tudo isso é feito automaticamente: uma ferramenta especial desfigura seu programa e verifica se os testes falharam.
, , , , , . : AST, .
Mutation Driven Development
mutation driven development. TDD, .
- , ( )
- ( if). , , MDD (?) , 100% overage TDD.
, CI, , , MDD .
, , . mutation driven testing , . , .. , , , , , ., 95% , - -. , .
Claro, discutiremos o desenvolvimento impulsionado por mutações em uma das próximas vendas de zinco , não se esqueça de assinar o podcast