e ligar todas estas coisas junto
até esta data
Certo
está pronto
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