Uma observação que deve ser feita a respeito de testes automatizados é a respeito dos objetivos que se tem com eles. Esses objetivos definem diretamente a abordagem que deve ser utilizada para a utilização de testes: antes ou depois da implementação.
Sua abordagem condiz com seu objetivo?
A abordagem de fazer os testes depois da implementação tem o objetivo de verificação, pois, nesse caso, os testes servem para garantir que o software continue funcionando da maneira implementada.
Por outro lado, a abordagem de fazer os testes antes da implementação tem como objetivo auxiliar no design da solução. Ver essa diferença é trivial, à medida que quando os testes são criados antes do código da funcionalidade ser criado, não há o que garantir que continue funcionando.
Tipos de testadores
De acordo com esses dois objetivos, existem também dois tipos de testadores: verificadores e designers. Esses dois grupos divergem basicamente na forma de encarar a relação testes-código.
O segundo grupo, os designers, se preocupam muito com a qualidade do código sendo desenvolvido. Para eles, o código deve ser elegante, simples e legível. Durante a codificação dos testes, quando um teste se torna muito complexo, é normal que sejam feitas refatorações no código principal, para que seja mais fácil testar. Isso acontece, pois quanto mais complexo, acoplado e menos coeso for um código mais complexo e maior serão os testes associados a ele. É comum para esse grupo, implementar testes antes ou, pelo menos, pensar nos testes e cenários antes, já que isso facilita a criação de um bom design.
É comum que não sejamos de um grupo ou de outro unicamente, mas parte de cada um dos dois. Afinal, os testes automatizados são ferramentas como várias outras e devem ser utilizadas da forma correta no momento oportuno para que se obtenha o melhor resultado.
É comum dizer que testadores do tipo verificadores estão preocupados com testes de cobertura também, como forma de evidenciar a integridade do código já feito, ou essa afirmação é equivocada?
ResponderExcluirParabens pelo artigo
Felipe, a afirmação é correta. Acredito que os dois grupos, e também nós que estamos entre esses grupos, se preocupam com a cobertura.
ResponderExcluirEssa métrica mostra a razão entre a quantidade de linhas que foram estressadas pelos testes em relação a quantidade de linhas total do projeto.
Enquanto os testadores miram na cobertura para garantir que não esqueceram de fazer testes para nenhuma parte, os designers utilizam a cobertura para checar se realmente os testes guiaram seu raciocínio ou se eles tiveram algum devaneio durante o desenvolvimento, ou seja, existe código que implementa um comportamento não previsto pelos casos de teste.
Independete do puritanismo da discussão de como um grupo ou outro encara a cobertura, essa métrica é muito interessante para identificar quais partes do programa não são exercitadas pelos testes. Isso pode servir para identificar que novos testes devem ser implementados ou que parte do código pode ter sua necessidade reavaliada.