Falsos negativos, falsos positivos, verdadeiros negativos e verdadeiros positivos…

… A importância desses conceitos

Os 4 tipos de testes que serão tratados neste post são, os dois primeiros, casos que devemos evitar (SEMPRE), e os dois últimos, nos quais devemos nos focar, quando estamos desenvolvendo testes automatizados.

Cada um será brevemente explicado a seguir:

Falsos negativos

Testes falhando, porém, devido a inconsistência no próprio teste e não na aplicação testada. Neste caso o teste deve ser corrigido, para não causar no time a sensação de que os testes estão os enganando. Estes testes DEVEM SER EVITADOS!

Falsos positivos

Testes passando, porém, que deviam estar falhando. Tão ou mais graves do que os falsos negativos, os falsos positivos escondem bugs existentes na aplicação, dizendo que uma funcionalidade está ok, quando na verdade há um bug. Estes testes necessitam de refactoring, para que revelem ao time quando um bug é introduzido na aplicação quando uma bateria de testes de regressão é executada, por exemplo. Eles também DEVEM SER EVITADOS!

Verdadeiros negativos

Testes falhando devido a falhas reais na aplicação em teste. São os testes que encontram bugs reais, valiosos para que o time tome ações rápidas para corrigir problemas verdadeiros na aplicação, devido a implementação de uma nova funcionalidade, correção de bug ou refatoração, que gerou efeitos colaterais (bugs).

Verdadeiros positivos

Testes que estão passando porque a aplicação está se comportando conforme o esperado. São testes que garantem a tranquilidade do time ao final do desenvolvimento de uma funcionalidade, da correção de uma porção de bugs, ou mesmo de uma completa mudança na arquitetura da aplicação, porém, que não impactou em nada com relação ao que já estava funcionando, ao menos do que já era coberto por testes automatizados.

Conclusão

Testes automatizados devem prover feedback real ao time que está desenvolvendo a aplicação, devem encontrar bugs reais o quanto antes possível, para que sejam corrigidos a tempo de que o usuário nem mesmo perceba, devem ser confiáveis e por isso mantidos como código de produção, e não devem ser deixados de lado, pois dentre outras questões, serão eles que ajudarão a garantir que a aplicação possa evoluir gradativamente.

Você tem algo a acrescentar? Deixe um comentário.