Em todo projeto bem planejado sempre se tem alguns critérios definidos em cada fase do projeto. Basicamente são os critérios de entrada, que define o que e como deve estar os artefatos/situações/infra que estão diretamente ligados aquela fase para que a mesma possa ser iniciada, e os critérios de saída que são os critérios que definem que uma determinada fase esta pronta para ser finalizada. Lembrando que nem sempre os critérios de saída de uma fase do projeto são também critérios de entrada de outra fase, principalmente nos dias atuais no qual o tempo é um fator crucial e os projetos raramente utilizam modelo de desenvolvimento em cascata para desenvolver o software e as fases de um projeto muitas vezes acontecem em paralelo.

Um dos critérios mais comuns em qualquer fase de um projeto de teste é a cobertura. Geralmente quando a conversa é com o cliente, se discute cobertura das funcionalidades e quando a conversa é com uma equipe de desenvolvedor, a conversa muitas vezes muda de escopo e passa a ser cobertura de código. Principalmente quando estamos falando num dos primeiros momentos em que teste dinâmico (Necessita de execução de código) se envolve em um projeto de desenvolvimento de software, que são com testes unitários. E um dos critérios de saída mais conhecidos na fase de desenvolvimento dos testes unitários são os de cobertura de código. Mas antes de conseguirmos calcular a porcentagem de cobertura dos testes unitários em relação ao software ou módulo deste software, precisamos definir qual a menor parte de código é considerada no projeto (linha de código, método, classe, etc.) e depois de implementarmos os testes unitários para exercitar esta menor parte de código é que podemos partir para próxima etapa. Ou o contrário se caso o projeto utilizar o processo de TDD (test driven development) no qual inicialmente temos apenas as assinaturas dos método e iniciamos primeiramente a implementação dos testes unitários para depois implementarmos o código do software. Geralmente os projetos que utilizam o TDD corretamente, possuem uma cobertura de código muito boa.

Para medirmos cobertura de código, além da definição da menor parte do software, a próxima estapa é definir a dimensão que nossos testes vão ser medidos,  pois as técnicas de cobertura apenas medem uma dimensão de um software por vez. Isso quer dizer que: Temos que ter cuidado quando falamos de 100% de cobertura. Podemos sim dizer que temos 100% de código coberto mas isso não a obrigatoriedade de termos 100% do código testado. Um exemplos disso  é:  Dois valores distintos de entrada podem exercitar as mesmas linhas de códigos mas uma pode encontrar um erro e a outra não.

Falando um pouco sobre as técnicas de medição de cobertura de código, as duas mais conhecidas são: Statement Coverage e Decision Coverage. A primeira nada mais é que a quantidade de números de linhas de código exercitados pelos testes, dividido pela quantidade total de linhas de código. Isso significa que se eu tenho um método com 10 linhas de código e um conjunto de testes que juntos executam 8 linhas de código daquele método, então posso dizer que a cobertura dos meus testes em relação ao método é de 80%. Quando falamos de decision coverage, a coisa não fica tão trivial assim. Decision coverage leva em conta se todas as linhas de códigos que possibilitam um ou mais caminhos de fluxo, foram completamente exercitados. Isso quer dizer que, estruturas de condição como: IF, CASE e estruturas de repetição como: DO-WHILE, REPEAT-UNTIL foram completamente exercitados pelos testes.

Complicado né ? Não se preocupem, no meu próximo post vou mostrar na prática como utilizar uma ferramenta, free obviamente, para medir a cobertura de código utilizando essas duas técnicas de medição.

Abracos e até a próxima.