Você testa bem seu código?
Geralmente, a métrica que utilizamos para cobertura de testes é o protection, normalmente calculado como parte de automações através de serviços como codecov ou CircleCI, essa métrica se dá normalmente através de linhas de código executadas em algum arquivo de teste, ou seja, se o código foi executado em algum teste ele é contabilizado como “testado”.
Para os mais entendidos, sabemos que execução puramente não nos trás segurança para dizer se algo está satisfatoriamente coberto ou não, existem diversos outros fatores que influenciam na qualidade dessa cobertura, entre eles podemos citar:
- Tipos de testes.
A famosa pirâmide de testes, unitários, integração, E2E… - Caminhos do código e valores de enter/output.
Condicionais, intervalos de valores, valores null, tipos, and many others… - Estado dos componentes que envolvem o teste.
Normalmente em testes de integração ou E2E, temos que ter muito cuidado para não gerarmos testes com falso positivo ou intermitentes (flaky, que passam arbitrariamente dependendo do estado, seja por não “limpar” o banco de dados, fila de mensagens, and many others…)
Dito isso, hoje quero trazer um pouco de minha experiência falando de “caminhos de código, valores de enter/output”
Apresentando o MC/DC
MC/DC ou “Modified Situation Determination Protection” é uma técnica de cobertura de testes para condições lógicas, ou seja, A > 18 AND B < 60.
A vantagem do MC/DC é que ele consegue reduzir drasticamente o número de casos que vamos implementar em nosso código de teste, sendo a redução de 2^n casos para (n+1).
Vou tentar ilustrar a técnica com a seguinte condição lógica A AND (B OR C)
A, B ou C seriam condições booleanas quaisquer, do dia a dia do seu código, por exemplo:
A = FeatureFlag.on()
B = order.is_enterprise()
C = order.transport <= SHIPPING_COST_LIMIT
Pela tabela verdade, teriámos 2^3 casos, ou seja, 8 combinações possivels. Porém conseguimos reduzir este número para 4 utilizando o MC/DC.
--+---+---+---+---+--
| R | A | B | C |
--+---+---+---+---+--
| 1 | 1 | 1 | 1 | A - é relevante (1, 7)
--+---+---+---+---+--
| 1 | 1 | 1 | 0 | C - é relevante (1, 2)
--+---+---+---+---+--
| 0 | 1 | 0 | 0 | B - é relevante (2, 3)
--+---+---+---+---+--
| 1 | 1 | 0 | 1 |
--+---+---+---+---+--
| 0 | 0 | 0 | 0 |
--+---+---+---+---+--
| 0 | 0 | 0 | 1 |
--+---+---+---+---+--
| 0 | 0 | 1 | 1 |
--+---+---+---+---+--
| 0 | 0 | 1 | 0 |
--+---+---+---+---+--
# R = Resultado da expression A AND (B OR C)
Resumidamente, com MC/DC precisamos achar os pares de expressão onde mantendo o resto constante e alterando somente a booleana analisada, alteramos o valor do resultado da expressão inteira.
Para exemplificar:
Vamos começar olhando pra booleana A.
Na linha 1, temos A = 1, B = 1 e C = 1.
Na linha 7, temos A – 0, B = 1 e C = 1.
Nesse exemplo, alteramos o valor de A mantendo B e C constante, brand, essa dupla de linhas é relevante para nosso caso.
Fazendo o mesmo raciocínio para o B e C, achamos os pares (1, 2) e (2, 3) respectivamente.
Dessa combinação, excluindo as linhas repetidas, ficamos com o resultado (1, 2, 3, 7).
Perceba como reduzimos o número de casos de teste de 2^n = 8 para (n+1) = 4.
Com esses casos em mãos podemos agora simplesmente implementá-los garantindo uma ótima cobertura sem de fato ter que implementar todos as possíveis combinações.
