5.8 - 5.11 - Cobertura,Teste Unitário x Integração, Outros Conceitos de Testes, e Perspectivas

Investimos bastante tempo

nas últimas aulas

falando sobre diferente tipos de teste

sobre teste unitário versus teste integrado

sobre como você pode usar RSpec

para de fato isolar as partes do seu código que você quer testar

você também sabe, devido ao "Homework 3",

e outras coisas, que fizemos BDD

onde utilizamos, principalmente, o Cucumber para transformar 'User Stories'

em testes de integração e aceitação

Você viu testes em alguns níveis diferentes

e o objetivo aqui é meio que fazer algums comentários

para relembrar um pouquinho

e conseguir ter uma visão mais abrangente

Isso meio que abrange o material

de três ou quato seções do livro

e eu gostaria the salientar os pontos importantes nas aulas

Uma questão que vem...

Eu tenho certeza que veio para todos vocês

quando vocês faziam o "homework"

é: "Quanto teste é o suficiente? "

E, tristemente, por um long período

se você perguntasse isto para a indústria

a resposta seria basicamente

"Nós temos uma data de lançamento limite,

assim, quanto conseguirmos fazer de teste

é o quanto temos que fazer de teste."

Certo? O quanto de tempo tiver.

Você sabe... isto é meio sarcástico

obviamente nada bom

Você pode fazer algo melhor, não?

Existem algumas medidas estáticas

como quantas linhas de código sua aplicação tem

e quantas linhas de teste você tem?

E não é raro na indústria

que para um pedaço de software bem testado

o número de linhas de teste

vá muito além do número de linhas de código

Assim, multiplicadores inteiros não são tão raros

E eu acho que mesmo para

código de pesquisa ou trabalho escolar

a proporção de, sei lá, talvez 1.5 não é absurda

assim uma vez e meia a quantidade de código de teste

para o código de aplicação

E em uma boa quantidade de sistemas de produção

onde eles realmente se importam com teste

é muito maior que isso

Então, talvez uma pergunta melhor a se fazer

ao invés de dizer: Quanto teste é suficiente?

seria melhor: Quão bom é o teste que estou fazendo agora?

Qão completo ele é?

Mais tarde neste semestre

O Professor Sen falará

um pouquinho sobre métodos formais

e quais são as fronteiras para teste e depuração

Mas a algumas coisas podemos falar agora

baseado no que você já sabe

sobre conceitos básicos de cobertura de testes

e embora eu diria

sei lá, temos falado o tempo todo

que métodos formais não funcionam para grandes sistemas

Eu penso que esta afirmação, em minha opinião pessoal

é hoje muito menos verdade do que costumava ser

Eu penso que existem alguns lugares específicos

especialmente em teste e depuração

onde métodos formais estão hoje fazendo rápido progresso

e Koushik Sen é um dos líderes nisso

Então, você terá a oportunidade de ouvir mais sobre isso depois

para agora, eu acho mais prático

falarmos sobre medir a cobertura

porque isso é a coisa mais importante

em termos de como você será avaliado

se você estiver fazendo isso pra valer

Então o que seria algo básico?

Aqui está uma classe bem simples que você pode usar

para falar sobre diferentes maneiras de medir

como nossos testes cobrem o código

e existem alguns níveis diferentes

com diferentes terminologias

Não é algo universal entre todas as escolas de software

mas um grupo comum de terminologias

que o livro expõe

e que poderíamos falar é S0

onde você deve chamar todos os métodos uma vez

De tal modo que, se você invocar 'foo', e invocar 'bar'

Isto é cobertura S0: não tão completo

Um pouco mais rigoroso é o S1

você poderia dizer, estamos invocando todos os métodos

de todos os lugares onde ele poderia ser invocado

Então o que isso significa?

Significa, por exemplo

que não basta apenas invocar 'bar'

Você tem que ter certeza que você deve invocá-lo

pelo menos uma vez daqui

assim como invocar uma vez

de todos as funções externas que podem invocá-lo

C0 é o que o "SimpleCov" mede

aqueles que colocaram "SimpleCov" para rodar

basicamente dizem que cada linha foi executada

que cada uma das linhas foi tocada uma vez em seu código

Mas o limitante ali é que

condicionais contam como uma única linha

Então, não importa em que ramo deste "if" você tocou

desde que você tenha tocado um dos outros ramos

então você executou a linha do "if"

Assim, mesmo "C0" meio que ainda oferece cobertura superficial

Mas, como veremos

o jeito que você deve ler esta informação é:

Se você estiver tendo uma cobertura ruim no nível 'C0'

então você realmente tem uma cobertura bem ruim

Se você não estiver fazendo

nem este nível simples de cobertura superficial

então seu teste é provavelmente deficiente

C1 é o próximo passo a frente

Poderíamos dizer:

Bem, temos que pegar cada ramo em ambas as direções

assim, quando estivermos nesta linha de "if"

temos que garantir que

fazemos uma vez a parte do "if x"

e a pelo menos uma vez a parte do "if not x"

C1, pode ampliar isso com decisão de cobertura

digamos: Bem, se vamos...

Se temos uma linha "if" onde a condição

é feita de múltiplos termos

temos que garantir que cada sub expressão

foi avaliada em ambas as direções

Em outra palavras, isso significa que

se vamos falhar esta linha do "if"

temos que ter certeza de falhá-la pelo menos uma vez

porque "y" era falso pelo menos uma vez porque "z" era falso

Em outras palavras, qualquer sub expressão que puder

mudar independente do resultado da condição

tem que ser exercitada em ambas as direções

e então tem uma que muita gente aspira

mas que não há consenso de quão mais valiosa seria

é que você tomaria todos os caminhos do código

Obviamente, isso é meio que difícil porque

tende a ser exponencial no número de condiçÕes

e de forma geral é difícil

de avaliar se você tomou cada um dos caminhos do código

Existem técnicas formais que você poderia usar

para te dizer onde os buracos estão

mas no final

na maioria das empresas de software

não existe um consenso completo

em quão mais valioso seria C2

comparado com C0 e C1

Assim, eu acho que para o propósito da nossa aula

e ligar todas estas coisas junto

até esta data

Certo

está pronto