1
00:00:00,040 --> 00:00:03,320
Olá, bem vindos. 
A mais uma análise aprofundada 

2
00:00:03,320 --> 00:00:08,680
aqui no nosso espaço hoje o foco
é um conceito é bem interessante

3
00:00:08,680 --> 00:00:12,040
da engenharia de software, 
testes de mutação. 

4
00:00:12,680 --> 00:00:16,000
A gente tá usando como base um 
capítulo didático sobre o 

5
00:00:16,000 --> 00:00:20,640
assunto do Marco Túlio Valente e
a nossa ideia aqui é destrinchar

6
00:00:20,640 --> 00:00:24,120
o que são esses testes, como 
eles operam e, claro, porque 

7
00:00:24,120 --> 00:00:26,520
eles são importantes, né? 
Para quem se preocupa com a 

8
00:00:26,520 --> 00:00:29,880
qualidade dos testes 
automatizados, vamos investigar 

9
00:00:29,880 --> 00:00:31,360
isso. 
Perfeito. 

10
00:00:31,600 --> 00:00:35,080
E olha o ponto de partida aqui, 
que é fundamental, é que testes 

11
00:00:35,080 --> 00:00:38,480
de mutação. 
Eles não buscam bugs diretamente

12
00:00:38,480 --> 00:00:41,240
no código que vai para produção,
sabe? 

13
00:00:41,440 --> 00:00:44,920
A finalidade é outra, é avaliar 
a qualidade. 

14
00:00:44,920 --> 00:00:48,360
AA efetividade dos testes que a 
gente já tem. 

15
00:00:48,800 --> 00:00:52,560
Basicamente é testar os nossos 
testes. 

16
00:00:52,760 --> 00:00:54,960
Interessante essa inversão de 
perspectiva. 

17
00:00:55,320 --> 00:00:58,480
Mas como é que isso funciona na 
prática? 

18
00:00:58,600 --> 00:01:00,800
Tem que mexer no código 
original, imagino. 

19
00:01:00,840 --> 00:01:02,760
Exato. 
A gente usa ferramentas 

20
00:01:02,760 --> 00:01:07,960
especializadas que fazem 
pequenas alterações, alterações 

21
00:01:07,960 --> 00:01:10,400
sintáticas mesmo no código fonte
original. 

22
00:01:10,640 --> 00:01:14,760
Coisas como, sei lá, trocar um 
operador, um mais por menos, 

23
00:01:14,760 --> 00:01:19,280
inverter uma condição lógica, um
if ou até remover uma chamada de

24
00:01:19,280 --> 00:01:22,520
método. 
Cada versão dessas alterada é o 

25
00:01:22,520 --> 00:01:25,200
que a gente chama de mutante. 
Ah, tá? 

26
00:01:25,400 --> 00:01:29,320
Pequenas mudanças para simular 
defeitos e a lógica então é que 

27
00:01:29,320 --> 00:01:33,400
se um teste automatizado que já 
existe é bom, ele deveria pegar 

28
00:01:33,400 --> 00:01:36,720
essa alteração, esse bug 
simulado e falhar. 

29
00:01:36,840 --> 00:01:41,840
Precisamente, se o teste roda no
código mutante e passa, ué, 

30
00:01:41,840 --> 00:01:44,800
significa que aquele teste 
específico não está cobrindo bem

31
00:01:44,800 --> 00:01:48,800
aquela parte do código ou aquele
cenário ali ele deixou o mutante

32
00:01:48,800 --> 00:01:51,280
sobreviver. 
E o que eu acho fascinante aqui 

33
00:01:51,280 --> 00:01:54,680
é como isso força a gente a 
pensar na cobertura real dos 

34
00:01:54,680 --> 00:01:58,480
testes, não só naquela cobertura
de linhas, que às vezes engana, 

35
00:01:58,480 --> 00:01:59,960
né? 
Faz todo o sentido ser uma 

36
00:01:59,960 --> 00:02:04,160
técnica caixa branca, então 
precisa conhecer o código por 

37
00:02:04,160 --> 00:02:06,680
dentro para poder fazer essas 
alterações. 

38
00:02:07,200 --> 00:02:09,360
A fonte até menciona um exemplo 
visual, né? 

39
00:02:09,560 --> 00:02:13,200
Mostrando tipo, Ah, um mutante 
sobreviveu aqui? 

40
00:02:13,560 --> 00:02:16,880
Então precisamos de um teste 
novo para matar esse cara 

41
00:02:16,880 --> 00:02:20,640
especificamente. 
E para medir isso, para 

42
00:02:20,640 --> 00:02:24,240
quantificar essa efetividade, a 
gente usa o tal do score de 

43
00:02:24,240 --> 00:02:27,080
mutações. 
A fórmula é bem simples, na 

44
00:02:27,080 --> 00:02:30,320
verdade, é o número de mutantes 
que foram mortos, ou seja, 

45
00:02:30,320 --> 00:02:34,600
detectados pelos testes dividido
pelo número total de mutantes 

46
00:02:34,600 --> 00:02:37,280
que a ferramenta gerou. 
O ideal, claro, seria chegar em 

47
00:02:37,280 --> 00:02:41,800
100%, significaria que todos os 
defeitos simulados foram pegos. 

48
00:02:41,840 --> 00:02:45,040
E já existem ferramentas mais 
estabelecidas para automatizar 

49
00:02:45,040 --> 00:02:47,240
isso, né? 
Você mencionou o pai teste, que 

50
00:02:47,240 --> 00:02:50,920
é bastante usado em Java. 
Mas imagino que a grande questão

51
00:02:50,920 --> 00:02:55,160
seja o tempo que isso leva gerar
e rodatestes para milhares, 

52
00:02:55,280 --> 00:02:58,080
talvez centenas de milhares de 
versões mutantes. 

53
00:02:58,320 --> 00:03:01,440
Isso não parece rápido? 
Sim, o tempo de execução é, sem 

54
00:03:01,440 --> 00:03:05,280
dúvida, o grande desafio. 
Ferramentas como OP teste são 

55
00:03:05,280 --> 00:03:08,080
bem espertas. 
Elas têm otimizações, por 

56
00:03:08,080 --> 00:03:11,520
exemplo, elas aplicam as 
mutações direto no bytecode, que

57
00:03:11,520 --> 00:03:14,960
é aquele código já compilado que
a máquina virtual Java executa, 

58
00:03:15,240 --> 00:03:19,160
e tentam rodar só os testes que 
são relevantes para cada mutante

59
00:03:19,160 --> 00:03:22,640
específico, mas ainda assim. 
Ainda assim, pode demorar 

60
00:03:22,640 --> 00:03:25,840
bastante. 
A teoria é muito legal, mas a 

61
00:03:25,840 --> 00:03:28,120
prática sempre traz esses 
obstáculos, né? 

62
00:03:28,840 --> 00:03:32,440
O exemplo que a fonte dá com a 
biblioteca j free chart ilustra 

63
00:03:32,440 --> 00:03:35,360
bem isso, eu acho. 
Ilustra perfeitamente. 

64
00:03:35,520 --> 00:03:39,280
Era um sistema assim de umas 
47000 linhas de código, mesmo 

65
00:03:39,280 --> 00:03:43,080
com as otimizações todas do 
piteste levou quase 2 horas para

66
00:03:43,080 --> 00:03:47,320
analisar mais de 250000 
mutantes. 2 horas. 

67
00:03:47,320 --> 00:03:50,880
Pensa nisso no ciclo de build de
integração contínua? 

68
00:03:51,120 --> 00:03:55,280
2 horas a mais é bastante coisa 
e o resultado, ainda por cima, 

69
00:03:55,280 --> 00:04:00,480
foi um escorde só 19%. 
Nossa. 19% é bem baixo. 

70
00:04:01,080 --> 00:04:05,360
Isso quer dizer que, 
potencialmente, 81% dos bugs 

71
00:04:05,360 --> 00:04:09,320
simples que foram simulados ali 
poderiam passar batido pelos 

72
00:04:09,320 --> 00:04:12,400
testes existentes. 
É um alerta e tanto, né? 

73
00:04:12,640 --> 00:04:16,160
Exatamente. 
É um indicador muito claro de 

74
00:04:16,160 --> 00:04:19,040
onde os testes precisam melhorar
naquele projeto. 

75
00:04:19,440 --> 00:04:23,080
Só que, por outro lado, as quase
2 horas de execução escancaram o

76
00:04:23,080 --> 00:04:25,840
custo computacional. 
É aquele trade of clássico da 

77
00:04:25,840 --> 00:04:28,320
engenharia. 
Você quer mais qualidade, mas 

78
00:04:28,320 --> 00:04:30,520
isso custa mais tempo, mais 
recurso. 

79
00:04:30,720 --> 00:04:33,760
E aí levanta a questão 
importante, quando que realmente

80
00:04:33,760 --> 00:04:35,920
vale a pena fazer esse 
investimento todo? 

81
00:04:36,200 --> 00:04:38,280
Pois é. 
E ainda tem outra complicação 

82
00:04:38,280 --> 00:04:41,640
que a fonte menciona os tais 
mutantes equivalentes. 

83
00:04:42,120 --> 00:04:44,780
Confesso que essa ideia me 
parece um pouco contra 

84
00:04:44,780 --> 00:04:47,440
intuitiva. 
Quer dizer que a ferramenta cria

85
00:04:47,440 --> 00:04:50,160
defeitos que na verdade, não são
defeitos. 

86
00:04:50,200 --> 00:04:52,520
Como assim? 
Sintaticamente, diferente do 

87
00:04:52,520 --> 00:04:55,120
original, por causa da mutação, 
ele produz exatamente o mesmo 

88
00:04:55,120 --> 00:04:57,800
comportamento externo. 
Pensa, por exemplo, numa mutação

89
00:04:57,800 --> 00:05:00,480
que cai dentro de um bloco de 
código que nunca é executado, o 

90
00:05:00,520 --> 00:05:03,360
famoso código morto. 
Não importa o que você mude ali,

91
00:05:03,360 --> 00:05:05,360
o resultado final do programa 
vai ser o mesmo. 

92
00:05:05,880 --> 00:05:08,480
Ah. 
Entendi e aí, nesse caso, não 

93
00:05:08,480 --> 00:05:11,200
tem teste no mundo que consiga 
matar esse? 

94
00:05:11,200 --> 00:05:14,240
Mutante porque ele não 
representa uma falha real que 

95
00:05:14,240 --> 00:05:16,600
alguém possa observar de fora, 
certo? 

96
00:05:17,320 --> 00:05:20,160
Como é que se lida com eles? 
Então, tem que identificar e 

97
00:05:20,160 --> 00:05:23,240
tirar da conta do score. 
Olha, detetar automaticamente 

98
00:05:23,240 --> 00:05:27,280
quais mutantes são equivalentes?
É um problema bem complexo na 

99
00:05:27,280 --> 00:05:30,040
computação. 
Muitas vezes a abordagem mais 

100
00:05:30,040 --> 00:05:32,680
prática não é nem tentar detetar
todos eles. 

101
00:05:33,000 --> 00:05:35,200
É mais analisar porque que eles 
surgiram. 

102
00:05:35,680 --> 00:05:38,680
Se um mutante sobreviveu e a 
gente vê que ele é equivalente 

103
00:05:38,680 --> 00:05:42,080
porque tá em código morto. 
Ora, a solução talvez seja 

104
00:05:42,080 --> 00:05:45,120
refaturar o código original e 
tirar aquele trecho inútil. 

105
00:05:45,480 --> 00:05:48,800
A própria existência do mutante 
equivalente pode ser um sintoma 

106
00:05:48,800 --> 00:05:51,120
de um probleminha de qualidade 
no código fonte. 

107
00:05:51,560 --> 00:05:55,200
Hum, interessante. 
Então, no fim das contas, o 

108
00:05:55,200 --> 00:05:59,080
grande valor dos testes de 
mutação é dar uma medida mais 

109
00:05:59,080 --> 00:06:03,440
rigorosa, mais profunda da 
qualidade da suíte de testes, 

110
00:06:03,800 --> 00:06:07,080
apontando fraquezas que a 
cobertura de linha sozinha não 

111
00:06:07,080 --> 00:06:09,360
mostra. 
Exatamente, eles são 

112
00:06:09,360 --> 00:06:13,200
especialmente valiosos em 
sistemas críticos, sabe? 

113
00:06:13,480 --> 00:06:18,600
Aplicações onde a confiança nos 
testes precisa ser máxima, mas é

114
00:06:18,600 --> 00:06:21,320
conectando isso com o quadro 
geral, com o dia a dia. 

115
00:06:21,520 --> 00:06:24,640
É preciso ter bom senso. 
Se uma equipe já sabe que os 

116
00:06:24,640 --> 00:06:28,360
testes dela tem falhas, já tem 
uma ideia de onde precisa 

117
00:06:28,360 --> 00:06:31,160
melhorar. 
Talvez o esforço computacional 

118
00:06:31,200 --> 00:06:35,560
enorme e análise dos resultados 
da mutação não sejam a 

119
00:06:35,560 --> 00:06:38,440
prioridade número 1 naquele 
momento específico. 

120
00:06:38,680 --> 00:06:41,440
Pode ser mais produtivo focar 
primeiro em consertar as 

121
00:06:41,440 --> 00:06:44,200
deficiências que já são óbvias. 
Entendi. 

122
00:06:44,360 --> 00:06:48,040
É uma ferramenta poderosa, sem 
dúvida, mas que exige um certo 

123
00:06:48,040 --> 00:06:51,960
discernimento sobre quando e 
como aplicar para tirar o melhor

124
00:06:51,960 --> 00:06:54,640
proveito dela. 
Bom, esperamos que essa análise 

125
00:06:54,640 --> 00:06:58,440
sobre teste de mutação tenha 
sido útil e esclarecedora para o

126
00:06:58,440 --> 00:07:01,200
pessoal que nos ouve. 
Com certeza, até a próxima.