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