A Complexidade Ciclomática é uma métrica interessante que pode, e deveria, constar entre as ferramentas utilizadas pelos desenvolvedores para aferir a respeito da qualidade de seu código. Ela foi criada em 1976 por Thomas McCabe, tratando-se de um cálculo que recebe como parâmetro um grafo correspondente ao fluxo de controle de seu código (seja este um método ou todo o programa). A complexidade aumenta com a quantidade de possíveis caminhos que um código pode seguir, por exemplo, a existência de um if dentro de um método cria dois caminhos possíveis para este: Um no qual o valor booleano testado pelo if é verdadeiro, outro no qual o valor é falso.
O ideal seria uma porção de código com apenas um único caminho, mas é difícil encontrar algo semelhante em um método, quanto mais em um programa. Desta forma, o desenvolvedor deve procurar o menor valor possível de complexidade para o seu código. Diversas boas práticas estão relacionadas com a diminuição da complexidade. Basta observar um código que procura simular com blocos if-else a funcionalidade de alguns design patterns, como Strategy e Abstract Factory. O resultado é um código massivamente complexo, com problemas de manutenção e propenso à bugs. Os problemas de um código com alto valor de complexidade vão muito além destes. Ele também se torna pouco coeso e de baixa legibilidade, por exemplo.
Através do teste de caminho básico é possível definir os diversos caminhos de execução do software e garantir que cada um deles seja executado ao menos uma vez (PRESSMAN, 1995). O número de caminhos é proporcional ao tamanho e complexidade do software. Devido aos módulos não trabalharem sozinhos, ou seja, são apenas partes de um sistema, fica inviável a utilização dos testes de estrutura. Dessa forma, testes de caminho básico são mais utilizados nos testes de unidade (SOMMERVILLE, 2003).
Antes de executar o teste de caminho básico é importante criar o modelo de representação do trecho de código a ser testado, para facilitar o entendimento do fluxo de controle. Nessa representação são utilizados fluxogramas e grafos. A figura 01 mostra um fluxograma simplificado de um teste de caminho básico.
O fluxograma pode ser facilmente representado em forma de grafos de fluxo
As linhas do grafo traçam os possíveis caminhos. É importante que a cada laço o teste utilize um caminho independente até que todos os caminhos sejam percorridos. Caminhos independentes são aqueles que executam instruções que ainda não foram executadas (PRESSMAN, 1995).
Para encontrar o número de caminhos independentes é necessário realizar o cálculo da complexidade ciclomática do grafo de fluxo do programa, esse cálculo é feito através da fórmula (SOMMERVILLE, 2003):
CC(G) = Número (ramos) – Número (nós) + 2,
sendo as setas correspondentes aos ramos e os círculos correspondentes aos nós, para o grafo de fluxo na figura 02, CC(G) = 11 – 9 + 2 = 4. Quatro é o número de caminhos independentes.
Caminhos independentes:
Caminho 1: 1-11
Caminho 2: 1-2-3-4-5-10-1-11
Caminho 3: 1-2-4-6-8-9-10-1-11
Caminho 4: 1-2-3-6-7-9-10-1-11
Caminho não independente:
Caminho 5: 1-2-3-4-5-10-1-2-3-6-8-9-10-1-11
O caminho 5 não é independente porque todas as suas instruções já foram executadas anteriormente, ou seja, não encontrou instruções ainda não executadas.
Pressman (1995) mostra duas outras maneiras de encontrar o número de caminhos independentes, além da fórmula apresentada por Sommerville (2003). Uma é encontrando o número de regiões (fechamento dos nós), que corresponde ao número de caminhos. A outra, o número de nós predicativos (nó que apresenta condicional) mais um corresponde ao número de caminhos independentes. De acordo com o grafo de fluxo:
CC(G) = Ramos – Nós + 2 = 11 – 9 + 2 = 4
CC(G) = Nós predicativos + 1 = 3 + 1 = 4
CC(G) = Regiões = 4 24
Genericamente, o teste de caminho básico não testa todas as combinações possíveis de todos os caminhos do software, pois, devido ao grande número de laços de repetições existentes, a quantidade de combinações de caminhos é infinita (SOMMERVILLE, 2003).
O teste de caminho básico é simples e eficaz, e ainda pode ser complementado por outros tipos de testes, para, assim, encontrar e corrigir o maior número possível de falhas, são eles o teste de condição, teste de fluxo de dados e o teste de laços (PRESSMAN, 1995).