9:59:59.000,9:59:59.000
e ligar todas estas coisas junto

9:59:59.000,9:59:59.000
até esta data

9:59:59.000,9:59:59.000
Certo

9:59:59.000,9:59:59.000
está pronto

0:00:00.579,0:00:01.922
Investimos bastante tempo

0:00:01.922,0:00:03.322
nas últimas aulas

0:00:03.322,0:00:05.821
falando sobre diferente tipos de teste

0:00:05.821,0:00:08.219
sobre teste unitário versus teste integrado

0:00:08.219,0:00:10.102
sobre como você pode usar RSpec

0:00:10.102,0:00:12.495
para de fato isolar as partes do seu código que você quer testar

0:00:12.495,0:00:14.906
você também sabe, devido ao "Homework 3",

0:00:14.906,0:00:18.176
e outras coisas, que fizemos BDD

0:00:18.176,0:00:20.621
onde utilizamos, principalmente, o Cucumber para transformar 'User Stories'

0:00:20.621,0:00:22.953
em testes de integração e aceitação

0:00:22.953,0:00:25.610
Você viu testes em alguns níveis diferentes

0:00:25.610,0:00:27.634
e o objetivo aqui é meio que fazer algums comentários

0:00:27.634,0:00:29.924
para relembrar um pouquinho

0:00:29.924,0:00:33.011
e conseguir ter uma visão mais abrangente

0:00:33.011,0:00:34.956
Isso meio que abrange o material

0:00:34.956,0:00:37.007
de três ou quato seções do livro

0:00:37.007,0:00:39.618
e eu gostaria the salientar os pontos importantes nas aulas

0:00:39.618,0:00:41.461
Uma questão que vem...

0:00:41.461,0:00:43.253
Eu tenho certeza que veio para todos vocês

0:00:43.253,0:00:44.526
quando vocês faziam o "homework"

0:00:44.526,0:00:45.695
é: "Quanto teste é o suficiente? "

0:00:45.695,0:00:48.497
E, tristemente, por um long período

0:00:48.497,0:00:51.090
se você perguntasse isto para a indústria

0:00:51.090,0:00:52.180
a resposta seria basicamente

0:00:52.180,0:00:53.179
"Nós temos uma data de lançamento limite,

0:00:53.179,0:00:55.000
assim, quanto conseguirmos fazer de teste

0:00:55.000,0:00:56.667
é o quanto temos que fazer de teste."

0:00:56.667,0:00:58.153
Certo? O quanto de tempo tiver.

0:00:58.153,0:01:00.024
Você sabe... isto é meio sarcástico

0:01:00.024,0:01:01.118
obviamente nada bom

0:01:01.118,0:01:02.549
Você pode fazer algo melhor, não?

0:01:02.549,0:01:03.702
Existem algumas medidas estáticas

0:01:03.702,0:01:06.034
como quantas linhas de código sua aplicação tem

0:01:06.034,0:01:08.216
e quantas linhas de teste você tem?

0:01:08.216,0:01:10.290
E não é raro na indústria

0:01:10.290,0:01:12.682
que para um pedaço de software bem testado

0:01:12.682,0:01:14.574
o número de linhas de teste

0:01:14.574,0:01:17.736
vá muito além do número de linhas de código

0:01:17.736,0:01:19.752
Assim, multiplicadores inteiros não são tão raros

0:01:19.752,0:01:21.843
E eu acho que mesmo para

0:01:21.843,0:01:23.229
código de pesquisa ou trabalho escolar

0:01:23.229,0:01:26.856
a proporção de, sei lá, talvez 1.5 não é absurda

0:01:26.856,0:01:30.058
assim uma vez e meia a quantidade de código de teste

0:01:30.058,0:01:32.249
para o código de aplicação

0:01:32.249,0:01:34.221
E em uma boa quantidade de sistemas de produção

0:01:34.221,0:01:35.277
onde eles realmente se importam com teste

0:01:35.277,0:01:36.919
é muito maior que isso

0:01:36.919,0:01:38.155
Então, talvez uma pergunta melhor a se fazer

0:01:38.155,0:01:39.472
ao invés de dizer: Quanto teste é suficiente?

0:01:39.472,0:01:42.493
seria melhor: Quão bom é o teste que estou fazendo agora?

0:01:42.493,0:01:44.351
Qão completo ele é?

0:01:44.351,0:01:45.565
Mais tarde neste semestre

0:01:45.565,0:01:46.568
O Professor Sen falará

0:01:46.568,0:01:48.189
um pouquinho sobre métodos formais

0:01:48.189,0:01:50.857
e quais são as fronteiras para teste e depuração

0:01:50.857,0:01:52.686
Mas a algumas coisas podemos falar agora

0:01:52.686,0:01:54.073
baseado no que você já sabe

0:01:54.073,0:01:57.744
sobre conceitos básicos de cobertura de testes

0:01:57.744,0:01:59.550
e embora eu diria

0:01:59.550,0:02:01.017
sei lá, temos falado o tempo todo

0:02:01.017,0:02:03.034
que métodos formais não funcionam para grandes sistemas

0:02:03.034,0:02:05.330
Eu penso que esta afirmação, em minha opinião pessoal

0:02:05.330,0:02:07.011
é hoje muito menos verdade do que costumava ser

0:02:07.011,0:02:09.190
Eu penso que existem alguns lugares específicos

0:02:09.190,0:02:10.524
especialmente em teste e depuração

0:02:10.524,0:02:12.848
onde métodos formais estão hoje fazendo rápido progresso

0:02:12.848,0:02:15.756
e Koushik Sen é um dos líderes nisso

0:02:15.756,0:02:17.944
Então, você terá a oportunidade de ouvir mais sobre isso depois

0:02:17.944,0:02:21.437
para agora, eu acho mais prático

0:02:21.437,0:02:22.734
falarmos sobre medir a cobertura

0:02:22.734,0:02:24.475
porque isso é a coisa mais importante

0:02:24.475,0:02:26.204
em termos de como você será avaliado

0:02:26.204,0:02:28.631
se você estiver fazendo isso pra valer

0:02:28.631,0:02:29.530
Então o que seria algo básico?

0:02:29.530,0:02:30.781
Aqui está uma classe bem simples que você pode usar

0:02:30.781,0:02:32.902
para falar sobre diferentes maneiras de medir

0:02:32.902,0:02:34.801
como nossos testes cobrem o código

0:02:34.801,0:02:36.632
e existem alguns níveis diferentes

0:02:36.632,0:02:37.851
com diferentes terminologias

0:02:37.851,0:02:40.737
Não é algo universal entre todas as escolas de software

0:02:40.737,0:02:42.641
mas um grupo comum de terminologias

0:02:42.641,0:02:43.647
que o livro expõe

0:02:43.647,0:02:44.689
e que poderíamos falar é S0

0:02:44.689,0:02:47.457
onde você deve chamar todos os métodos uma vez

0:02:47.457,0:02:50.452
De tal modo que, se você invocar 'foo', e invocar 'bar'

0:02:50.452,0:02:52.150
Isto é cobertura S0: não tão completo

0:02:52.150,0:02:54.688
Um pouco mais rigoroso é o S1

0:02:54.688,0:02:56.137
você poderia dizer, estamos invocando todos os métodos

0:02:56.137,0:02:57.288
de todos os lugares onde ele poderia ser invocado

0:02:57.288,0:02:58.820
Então o que isso significa?

0:02:58.820,0:03:00.076
Significa, por exemplo

0:03:00.076,0:03:01.124
que não basta apenas invocar 'bar'

0:03:01.124,0:03:02.952
Você tem que ter certeza que você deve invocá-lo

0:03:02.952,0:03:05.575
pelo menos uma vez daqui

0:03:05.575,0:03:07.161
assim como invocar uma vez

0:03:07.161,0:03:10.370
de todos as funções externas que podem invocá-lo

0:03:10.370,0:03:12.820
C0 é o que o "SimpleCov" mede

0:03:12.820,0:03:15.997
aqueles que colocaram "SimpleCov" para rodar

0:03:15.997,0:03:18.522
basicamente dizem que cada linha foi executada

0:03:18.522,0:03:20.045
que cada uma das linhas foi tocada uma vez em seu código

0:03:20.045,0:03:22.483
Mas o limitante ali é que

0:03:22.483,0:03:25.587
condicionais contam como uma única linha

0:03:25.587,0:03:28.915
Então, não importa em que ramo deste "if" você tocou

0:03:28.915,0:03:31.749
desde que você tenha tocado um dos outros ramos

0:03:31.749,0:03:33.350
então você executou a linha do "if"

0:03:33.350,0:03:35.670
Assim, mesmo "C0" meio que ainda oferece cobertura superficial

0:03:35.670,0:03:37.267
Mas, como veremos

0:03:37.267,0:03:39.231
o jeito que você deve ler esta informação é:

0:03:39.231,0:03:41.792
Se você estiver tendo uma cobertura ruim no nível 'C0'

0:03:41.792,0:03:44.072
então você realmente tem uma cobertura bem ruim

0:03:44.072,0:03:46.082
Se você não estiver fazendo

0:03:46.082,0:03:47.370
nem este nível simples de cobertura superficial

0:03:47.370,0:03:50.021
então seu teste é provavelmente deficiente

0:03:50.021,0:03:51.916
C1 é o próximo passo a frente

0:03:51.916,0:03:53.719
Poderíamos dizer:

0:03:53.719,0:03:55.198
Bem, temos que pegar cada ramo em ambas as direções

0:03:55.198,0:03:56.617
assim, quando estivermos nesta linha de "if"

0:03:56.617,0:03:58.667
temos que garantir que

0:03:58.667,0:03:59.923
fazemos uma vez a parte do "if x"

0:03:59.923,0:04:05.137
e a pelo menos uma vez a parte do "if not x"

0:04:05.137,0:04:08.361
C1, pode ampliar isso com decisão de cobertura

0:04:08.361,0:04:09.638
digamos: Bem, se vamos...

0:04:09.638,0:04:12.369
Se temos uma linha "if" onde a condição

0:04:12.369,0:04:13.890
é feita de múltiplos termos

0:04:13.890,0:04:15.716
temos que garantir que cada sub expressão

0:04:15.716,0:04:17.972
foi avaliada em ambas as direções

0:04:17.972,0:04:19.678
Em outra palavras, isso significa que

0:04:19.678,0:04:22.411
se vamos falhar esta linha do "if"

0:04:22.411,0:04:24.348
temos que ter certeza de falhá-la pelo menos uma vez

0:04:24.348,0:04:26.448
porque "y" era falso pelo menos uma vez porque "z" era falso

0:04:26.448,0:04:28.889
Em outras palavras, qualquer sub expressão que puder

0:04:28.889,0:04:31.214
mudar independente do resultado da condição

0:04:31.214,0:04:34.483
tem que ser exercitada em ambas as direções

0:04:36.038,0:04:38.523
e então tem uma que muita gente aspira

0:04:38.523,0:04:41.264
mas que não há consenso de quão mais valiosa seria

0:04:41.264,0:04:42.834
é que você tomaria todos os caminhos do código

0:04:42.834,0:04:45.537
Obviamente, isso é meio que difícil porque

0:04:45.537,0:04:48.331
tende a ser exponencial no número de condiçÕes

0:04:48.331,0:04:53.088
e de forma geral é difícil

0:04:53.088,0:04:55.312
de avaliar se você tomou cada um dos caminhos do código

0:04:55.312,0:04:57.015
Existem técnicas formais que você poderia usar

0:04:57.015,0:04:58.833
para te dizer onde os buracos estão

0:04:58.833,0:05:01.311
mas no final

0:05:01.311,0:05:03.050
na maioria das empresas de software

0:05:03.050,0:05:04.891
não existe um consenso completo

0:05:04.891,0:05:06.708
em quão mais valioso seria C2

0:05:06.708,0:05:08.685
comparado com C0 e C1

0:05:08.685,0:05:10.138
Assim, eu acho que para o propósito da nossa aula