1
00:00:02,939 --> 00:00:07,179
Deixe-me falar brevemente sobre testes angulares.

2
00:00:07,179 --> 00:00:11,125
Como você projeta suas aplicações angulares para serem testáveis?

3
00:00:11,125 --> 00:00:14,032
Como você desenha os testes para sua aplicação angular?

4
00:00:14,032 --> 00:00:16,359
Como você executa os testes e certifique-se de que

5
00:00:16,359 --> 00:00:20,607
sua aplicação angular está satisfazendo todos os testes que você tem

6
00:00:20,607 --> 00:00:25,210
escreveu mesmo quando você está desenvolvendo sua aplicação angular?

7
00:00:25,210 --> 00:00:27,394
Agora é aqui que eu também falaria brevemente sobre

8
00:00:27,394 --> 00:00:31,209
desenvolvimento orientado por testes de aplicações angulares.

9
00:00:31,209 --> 00:00:37,225
Curiosamente, o próprio angular foi construído a partir do zero para permitir o teste,

10
00:00:37,225 --> 00:00:40,820
para fazer parte do seu desenvolvimento de aplicações angulares.

11
00:00:40,820 --> 00:00:47,844
A força principal por trás angular Misko Hevy era ele mesmo um engenheiro de testes do Google e, portanto,

12
00:00:47,844 --> 00:00:51,850
sua influência no design angular para ser testável a partir

13
00:00:51,850 --> 00:00:56,479
ground up pode ser facilmente visto em toda a estrutura.

14
00:00:56,479 --> 00:01:04,435
Então, angular em si como você entendeu a partir das palestras e exercícios anteriores,

15
00:01:04,435 --> 00:01:07,224
é de natureza modular.

16
00:01:07,224 --> 00:01:11,155
Assim, os módulos de angular juntamente com os componentes e

17
00:01:11,155 --> 00:01:17,409
seus modelos e, em seguida, os serviços e os tubos e as directivas,

18
00:01:17,409 --> 00:01:23,559
significa que angular se presta facilmente para ser testado.

19
00:01:23,559 --> 00:01:29,049
Agora, porque a aplicação angular em si é composta por essas várias partes,

20
00:01:29,049 --> 00:01:32,319
você pode testar cada uma dessas partes em isolamento primeiro

21
00:01:32,319 --> 00:01:36,719
mesmo antes que eles se tornem parte de toda a aplicação angular.

22
00:01:36,719 --> 00:01:40,820
O segundo aspecto é o mecanismo de injeção de dependência que angular alavanca

23
00:01:40,820 --> 00:01:45,969
para apoiar a combinação das várias partes de

24
00:01:45,969 --> 00:01:52,120
sua aplicação angular em si significa que você pode facilmente substituir zomba

25
00:01:52,120 --> 00:01:54,340
para essas dependências dentro

26
00:01:54,340 --> 00:01:59,165
suas várias partes do angular aplicação e realizar testes.

27
00:01:59,165 --> 00:02:01,135
Eu usei a palavra zombar em,

28
00:02:01,135 --> 00:02:05,409
na frase anterior virá a entender

29
00:02:05,409 --> 00:02:10,194
que em um pouco mais de detalhes e mais que, slides posteriores.

30
00:02:10,194 --> 00:02:14,439
É aqui que precisamos estar cientes de

31
00:02:14,439 --> 00:02:19,724
uma abordagem para fazer desenvolvimento de aplicativos chamada desenvolvimento orientado a testes.

32
00:02:19,724 --> 00:02:26,155
No desenvolvimento orientado por testes, como você pode entender pelo próprio nome,

33
00:02:26,155 --> 00:02:29,229
significa que você primeiro escreve testes automatizados para

34
00:02:29,229 --> 00:02:33,389
todas as funcionalidades que você deseja implementar em seu aplicativo.

35
00:02:33,389 --> 00:02:35,004
Então primeiro vem o teste,

36
00:02:35,004 --> 00:02:39,180
depois você escreve o código do aplicativo para passar no teste.

37
00:02:39,180 --> 00:02:44,634
Então, o teste em si especifica qual funcionalidade você deseja implementar.

38
00:02:44,634 --> 00:02:47,840
Depois disso, você escreve o código para implementar essa funcionalidade.

39
00:02:47,840 --> 00:02:50,165
Como você já tem o teste no lugar,

40
00:02:50,165 --> 00:02:58,150
você pode testar para ver se a implementação que você faz satisfaz o teste ou não.

41
00:02:58,150 --> 00:03:04,735
Agora, é claro, uma vez que sua realização de sua funcionalidade satisfaz o teste,

42
00:03:04,735 --> 00:03:10,919
você sempre pode refatorar o código para estar em conformidade com seus padrões de engenharia de software.

43
00:03:10,919 --> 00:03:12,939
Mas mesmo depois disso,

44
00:03:12,939 --> 00:03:16,900
você pode testar novamente o código para se certificar de que ele ainda satisfaz

45
00:03:16,900 --> 00:03:20,844
os requisitos especificados dentro

46
00:03:20,844 --> 00:03:25,914
que teste específico que você usa dentro de seu desenvolvimento orientado por teste.

47
00:03:25,914 --> 00:03:28,659
Então, de fato, o desenvolvimento orientado para testes é

48
00:03:28,659 --> 00:03:32,199
uma abordagem muito viável para projetar

49
00:03:32,199 --> 00:03:36,522
boa aplicação desde o zero para ser totalmente testado.

50
00:03:36,522 --> 00:03:38,340
Agora, quando falamos sobre testes,

51
00:03:38,340 --> 00:03:42,009
você pode abordar testes de vários aspectos diferentes.

52
00:03:42,009 --> 00:03:44,889
O primeiro e acima de tudo é que se o seu aplicativo

53
00:03:44,889 --> 00:03:48,534
em si é implementado como várias peças,

54
00:03:48,534 --> 00:03:52,620
como componentes, como serviços, como diretivas,

55
00:03:52,620 --> 00:03:57,760
como os pipes que você está implementando dentro de sua aplicação.

56
00:03:57,760 --> 00:04:03,120
Isso significa que você pode facilmente testar cada uma dessas unidades individuais isoladamente.

57
00:04:03,120 --> 00:04:06,435
Então é aí que os testes unitários vêm à tona.

58
00:04:06,435 --> 00:04:10,675
Teste de unidade significa que você está testando as unidades individuais de código,

59
00:04:10,675 --> 00:04:13,750
certificando-se de que essa unidade individual

60
00:04:13,750 --> 00:04:18,759
satisfaz a funcionalidade que é suposto suportar,

61
00:04:18,759 --> 00:04:25,855
e que a funcionalidade e a lógica dentro desse pedaço de código é implementada corretamente.

62
00:04:25,855 --> 00:04:28,870
Agora isolar a unidade e testar é muito,

63
00:04:28,870 --> 00:04:35,401
muito útil descobrir a maioria dos problemas iniciais dentro do seu,

64
00:04:35,401 --> 00:04:41,079
dentro do seu código e, em seguida, corrigi-los mesmo antes de integrar esse patch no código.

65
00:04:41,079 --> 00:04:44,259
Agora, uma vez que você começa a integrar essas partes no todo,

66
00:04:44,259 --> 00:04:50,860
torna-se ainda mais complicado ser capaz de realizar testes detalhados de seu código.

67
00:04:50,860 --> 00:04:55,839
Assim, portanto, testes unitários isolados formam a primeira linha

68
00:04:55,839 --> 00:05:01,029
de defesa contra bugs quando você está desenvolvendo sua aplicação,

69
00:05:01,029 --> 00:05:03,904
especificamente sua aplicação angular.

70
00:05:03,904 --> 00:05:06,189
Agora, como vemos com um angular,

71
00:05:06,189 --> 00:05:10,540
temos uma clara separação entre os componentes angulares e o próprio DOM.

72
00:05:10,540 --> 00:05:13,339
Assim, dentro de um componente, por exemplo, lá,

73
00:05:13,339 --> 00:05:16,930
a lógica do seu componente é implementada completamente em

74
00:05:16,930 --> 00:05:22,101
o código datilografado que você implementou dentro de um componente que digitaliza arquivos.

75
00:05:22,101 --> 00:05:25,675
E então o DOM em si é controlado através

76
00:05:25,675 --> 00:05:29,660
o modelo que você projetou para o seu componente angular.

77
00:05:29,660 --> 00:05:33,475
Então Beta em si, você vê a clara separação entre os dois.

78
00:05:33,475 --> 00:05:36,139
Então você poderia simplesmente testar apenas a lógica de

79
00:05:36,139 --> 00:05:41,615
seu código de componente em si sem escrever um modelo vertical.

80
00:05:41,615 --> 00:05:47,350
Mas então você também pode considerar os dois juntos e, em seguida, avaliar esses aspectos.

81
00:05:47,350 --> 00:05:50,731
Como veremos no exercício que se segue a esta palestra,

82
00:05:50,731 --> 00:05:53,879
vamos realmente fazer ambas as abordagens.

83
00:05:53,879 --> 00:05:56,685
Não só isso, o fato de que angular usa a injeção de dependência

84
00:05:56,685 --> 00:06:01,910
significa que você pode injetar dependências simuladas dentro da sua aplicação.

85
00:06:01,910 --> 00:06:04,279
Quando eu digo simular, quero dizer, por exemplo,

86
00:06:04,279 --> 00:06:08,500
se seu componente depende de um serviço específico, você sempre pode implementar

87
00:06:08,500 --> 00:06:13,220
um serviço simulado que imita o comportamento do serviço

88
00:06:13,220 --> 00:06:17,689
e, em seguida, substituir no lugar enquanto você está testando o componente para que você possa manter

89
00:06:17,689 --> 00:06:22,550
seu componente independente de como o serviço é realmente implementado.

90
00:06:22,550 --> 00:06:27,110
Enquanto a interface entre seu componente e o serviço for projetada corretamente

91
00:06:27,110 --> 00:06:32,045
, você poderá substituir um serviço simulado no local e ainda testar seu componente.

92
00:06:32,045 --> 00:06:33,784
Lá, do simulador,

93
00:06:33,784 --> 00:06:39,470
você pode facilmente controlar o que é fornecido ao componente a partir do serviço.

94
00:06:39,470 --> 00:06:43,220
Portanto, esta abordagem permite que você faça testes de unidade

95
00:06:43,220 --> 00:06:47,990
em grande detalhe dentro da sua aplicação angular.

96
00:06:47,990 --> 00:06:53,375
Aqui é onde a disponibilidade de frameworks de teste como “Jasmine”.

97
00:06:53,375 --> 00:06:55,459
Então, o que Jasmine fornece é

98
00:06:55,459 --> 00:07:03,110
um framework de teste orientado pelo comportamento que é completamente projetado em JavaScript.

99
00:07:03,110 --> 00:07:06,170
Agora, esta estrutura Jasmine é uma estrutura geral que

100
00:07:06,170 --> 00:07:09,505
está disponível para testar qualquer aplicativo JavaScript.

101
00:07:09,505 --> 00:07:18,565
Angular adota Jasmine como a abordagem para especificar nossos testes para outras partes angulares,

102
00:07:18,565 --> 00:07:23,657
seus componentes, os serviços e vários aspectos de nossa aplicação angular.

103
00:07:23,657 --> 00:07:30,730
Agora, dentro de Jasmine, Jasmine usa duas coisas que vem em seu auxílio.

104
00:07:30,730 --> 00:07:33,722
Um deles é o uso de uma função “descrever”.

105
00:07:33,722 --> 00:07:38,779
A função “descrever” permite agrupar um conjunto de testes e, em seguida,

106
00:07:38,779 --> 00:07:45,110
executar esses testes juntos como um único grupo de testes.

107
00:07:45,110 --> 00:07:47,884
Quando escrevemos o código no exercício você vai me ver

108
00:07:47,884 --> 00:07:52,225
encerrando um conjunto de testes dentro de uma função de descrever.

109
00:07:52,225 --> 00:07:55,389
Então escrevemos o nosso código para o nosso,

110
00:07:55,389 --> 00:08:00,214
o código Jasmine, para os nossos testes angulares.

111
00:08:00,214 --> 00:08:05,171
Agora, dentro dessas funções “descrever”, você também usará o que é chamado de funções “it”.

112
00:08:05,171 --> 00:08:07,550
As funções “it” permitem especificar

113
00:08:07,550 --> 00:08:11,949
testes individuais que você deseja realizar em sua aplicação angular.

114
00:08:11,949 --> 00:08:17,509
Então é onde você vai me ver especificando “it” e, em seguida, especificar que

115
00:08:17,509 --> 00:08:21,185
a natureza do teste particular e, em seguida,

116
00:08:21,185 --> 00:08:25,259
projetar o código para esse teste específico com uma função in “it”.

117
00:08:25,259 --> 00:08:29,240
Então, à medida que projetamos o código no exercício, procure o “descrever” e

118
00:08:29,240 --> 00:08:33,575
o “it” dentro de suas aplicações de teste angular.

119
00:08:33,575 --> 00:08:37,559
Uma vez desenhado o teste com o framework Jasmine,

120
00:08:37,559 --> 00:08:41,600
Karma é uma ferramenta de linha de comando com base em JavaScript

121
00:08:41,600 --> 00:08:46,174
que permite realizar estes testes automaticamente.

122
00:08:46,174 --> 00:08:48,440
Agora, Karma junto com Jasmine,

123
00:08:48,440 --> 00:08:53,500
permite que você realize testes para sua aplicação angular.

124
00:08:53,500 --> 00:08:56,375
Agora com Karma, o que Karma suporta,

125
00:08:56,375 --> 00:08:59,065
é que ele permite que você crie

126
00:08:59,065 --> 00:09:04,409
um servidor web dentro do qual você carrega o código-fonte do aplicativo e

127
00:09:04,409 --> 00:09:13,370
em seguida, Karma usa um navegador para realizar os testes reais de suas várias unidades.

128
00:09:13,370 --> 00:09:17,100
Então é aqui que quando você executa seus testes usando Karma,

129
00:09:17,100 --> 00:09:19,774
você verá Karma empilhando um navegador,

130
00:09:19,774 --> 00:09:26,120
se é uma janela de navegador de um navegador existente ou

131
00:09:26,120 --> 00:09:29,174
se você usaria algo chamado PhantomJS que começa

132
00:09:29,174 --> 00:09:32,715
um navegador fantasma nos bastidores para realizar o teste.

133
00:09:32,715 --> 00:09:35,855
Não importa, mas Karma usa

134
00:09:35,855 --> 00:09:40,554
o navegador em um momento para realizar o teste para sua aplicação angular.

135
00:09:40,554 --> 00:09:43,356
Como você verá no exercício que se segue,

136
00:09:43,356 --> 00:09:50,649
aqui é onde se um de seus colegas continua insistindo que sua implementação de

137
00:09:50,649 --> 00:09:55,070
um determinado pedaço de sua aplicação angular é

138
00:09:55,070 --> 00:09:59,659
correto e continua enfatizando o ponto,

139
00:09:59,659 --> 00:10:03,110
você sempre pode projetar alguns testes usando Jasmine e

140
00:10:03,110 --> 00:10:07,081
Karma e, em seguida, realizar os testes e se os testes falharem,

141
00:10:07,081 --> 00:10:11,095
você sempre pode refutar seu argumento.

142
00:10:11,095 --> 00:10:12,615
Então é quando você pode virar,

143
00:10:12,615 --> 00:10:14,465
virar para seu colega e dizer,

144
00:10:14,465 --> 00:10:17,240
meu Karma atropelou seu dogma.

145
00:10:17,240 --> 00:10:21,664
Agora, é claro, suas aplicações angulares não são completamente desprovidas

146
00:10:21,664 --> 00:10:26,419
do envolvimento da própria estrutura angular.

147
00:10:26,419 --> 00:10:29,210
Seu componente não pode ser projetado sozinho sem

148
00:10:29,210 --> 00:10:33,850
usando muitas das funcionalidades da biblioteca que angular fornece para você,

149
00:10:33,850 --> 00:10:39,215
embora algumas das lógicas básicas possam ser testadas independentemente do angular.

150
00:10:39,215 --> 00:10:42,125
O que chamamos de testes isolados.

151
00:10:42,125 --> 00:10:44,450
Mas, mais e mais,

152
00:10:44,450 --> 00:10:46,659
você vai descobrir que a menos que você em,

153
00:10:46,659 --> 00:10:49,490
quer o suporte de quadro angular em si você

154
00:10:49,490 --> 00:10:52,565
não será capaz de realizar grande parte do teste de

155
00:10:52,565 --> 00:11:00,639
suas partes angulares se é componentes ou serviços ou tubos ou directivas.

156
00:11:00,639 --> 00:11:05,524
Então é aqui que os utilitários de teste angulares fornecem

157
00:11:05,524 --> 00:11:08,690
um ambiente de teste que permite que você realize

158
00:11:08,690 --> 00:11:12,384
os testes unitários dentro de sua aplicação angular.

159
00:11:12,384 --> 00:11:18,139
Então, os utilitários de teste angular como você vai me ver usando nos exercícios,

160
00:11:18,139 --> 00:11:20,480
no próximo exercício,

161
00:11:20,480 --> 00:11:27,034
nos fornecerá certas implementações de funcionalidade angular que você usa

162
00:11:27,034 --> 00:11:33,950
dentro de seus testes, a fim de configurar o ambiente onde você pode realizar seus testes.

163
00:11:33,950 --> 00:11:37,319
Então, este é o lugar onde a interação com o ambiente angular,

164
00:11:37,319 --> 00:11:41,404
em vez de usar as implementações angulares reais,

165
00:11:41,404 --> 00:11:45,740
você vai usar este utilitário de teste que irá fornecer

166
00:11:45,740 --> 00:11:50,355
funcionalidade suficiente para permitir que você realize os testes.

167
00:11:50,355 --> 00:11:53,840
E é aqui que o TestBed que vamos

168
00:11:53,840 --> 00:11:57,825
usar dentro da nossa aplicação angular é muito, muito útil.

169
00:11:57,825 --> 00:12:02,899
O TestBed cria essencialmente um modular de teste angular.

170
00:12:02,899 --> 00:12:06,205
Como você percebe, seus componentes não existem sozinhos.

171
00:12:06,205 --> 00:12:09,850
Seus componentes devem ser incluídos dentro de um módulo NG.

172
00:12:09,850 --> 00:12:14,264
Agora você não pode simplesmente usar um módulo NG padrão para realizar seus testes.

173
00:12:14,264 --> 00:12:16,084
Então é aí que o TestBed,

174
00:12:16,084 --> 00:12:18,560
que é suportado pelo utilitário de teste angular,

175
00:12:18,560 --> 00:12:24,549
fornece um ambiente de módulo NG que permite testar seus componentes.

176
00:12:24,549 --> 00:12:25,850
Então, dentro do TestBed,

177
00:12:25,850 --> 00:12:29,929
você usará algo chamado TestBed Create Component para criar

178
00:12:29,929 --> 00:12:36,139
um componente individual e uma instância do componente para realizar os testes sobre isso.

179
00:12:36,139 --> 00:12:37,940
E quando você faz isso

180
00:12:37,940 --> 00:12:42,454
o TestBed dá acesso a algo chamado ComponentFixture,

181
00:12:42,454 --> 00:12:48,500
o ComponentFixture é algo que fornece um identificador que permite que você envolva

182
00:12:48,500 --> 00:12:56,419
seu componente com funcionalidade suficiente para que o componente possa ser testado por si só.

183
00:12:56,419 --> 00:13:00,950
O fixture fornece acesso ao próprio componente e

184
00:13:00,950 --> 00:13:05,299
, em seguida, também através de que vamos usar algo chamado DebugeLement.

185
00:13:05,299 --> 00:13:08,375
Você vai me ver usando isso no exercício que se segue.

186
00:13:08,375 --> 00:13:11,424
O DepureLement dá-lhe acesso ao DOM,

187
00:13:11,424 --> 00:13:16,754
que é o modelo suportado como parte do seu componente.

188
00:13:16,754 --> 00:13:23,899
Assim, você pode fazer manipulações no DOM como clicar em elementos no DOM,

189
00:13:23,899 --> 00:13:29,315
obter acesso a um elemento DOM e, em seguida, ler o que está incluído

190
00:13:29,315 --> 00:13:35,600
dentro desses elementos Dom e assim por diante que lhe permitirá realizar os testes.

191
00:13:35,600 --> 00:13:37,669
Agora, antes de prosseguirmos para o exercício,

192
00:13:37,669 --> 00:13:43,250
Eu quero que você esteja ciente de algumas dessas coisas para que quando as encontrarmos em

193
00:13:43,250 --> 00:13:51,139
o exercício em si, você verá por que estou fazendo uso de cada uma dessas peças diferentes.