1
00:00:02,939 --> 00:00:07,179
Lasciate che vi parli brevemente dei test angolari.

2
00:00:07,179 --> 00:00:11,125
Come progetti le tue applicazioni angolari per essere testabili?

3
00:00:11,125 --> 00:00:14,032
Come progetti i test per la tua applicazione angolare?

4
00:00:14,032 --> 00:00:16,359
Come esegui i test e assicurati che

5
00:00:16,359 --> 00:00:20,607
la tua applicazione angolare soddisfi tutti i test che hai

6
00:00:20,607 --> 00:00:25,210
scritto anche mentre stai sviluppando la tua applicazione angolare?

7
00:00:25,210 --> 00:00:27,394
Ora questo è dove vorrei anche parlare brevemente

8
00:00:27,394 --> 00:00:31,209
dello sviluppo guidato da test di applicazioni angolari.

9
00:00:31,209 --> 00:00:37,225
È interessante notare che angolare stesso è stato costruito da zero per consentire

10
00:00:37,225 --> 00:00:40,820
il test, per far parte dello sviluppo dell'applicazione angolare.

11
00:00:40,820 --> 00:00:47,844
La forza principale dietro angolare Misko Hvery era lui stesso un ingegnere di test di Google e, quindi,

12
00:00:47,844 --> 00:00:51,850
la sua influenza sulla progettazione angolare per essere testabile

13
00:00:51,850 --> 00:00:56,479
da terra può essere facilmente vista in tutto il framework.

14
00:00:56,479 --> 00:01:04,435
Quindi, angolare stesso come hai capito dalle lezioni ed esercizi precedenti,

15
00:01:04,435 --> 00:01:07,224
è di natura modulare.

16
00:01:07,224 --> 00:01:11,155
Quindi i moduli di angolare insieme ai componenti e ai

17
00:01:11,155 --> 00:01:17,409
loro modelli e poi i servizi e le tubazioni e le direttive,

18
00:01:17,409 --> 00:01:23,559
significano che angolare si presta facilmente per essere testato.

19
00:01:23,559 --> 00:01:29,049
Ora, poiché l'applicazione angolare stessa è composta da queste varie parti, è

20
00:01:29,049 --> 00:01:32,319
possibile testare ognuna di queste parti in isolamento prima

21
00:01:32,319 --> 00:01:36,719
anche prima che diventino parte dell'intera applicazione angolare.

22
00:01:36,719 --> 00:01:40,820
Il secondo aspetto è il meccanismo di iniezione delle dipendenze che angolare sfrutta

23
00:01:40,820 --> 00:01:45,969
per supportare la combinazione delle varie parti dell'

24
00:01:45,969 --> 00:01:52,120
applicazione angolare stessa significa che puoi facilmente sostituire i mock

25
00:01:52,120 --> 00:01:54,340
per quelle dipendenze all'interno delle

26
00:01:54,340 --> 00:01:59,165
tue varie parti dell'applicazione angolare e effettuare le prove.

27
00:01:59,165 --> 00:02:01,135
Ho usato la parola mock in,

28
00:02:01,135 --> 00:02:05,409
nella frase precedente verrà a capire

29
00:02:05,409 --> 00:02:10,194
che in un po 'più dettagliato e più che, diapositive successive.

30
00:02:10,194 --> 00:02:14,439
Questo è dove dobbiamo essere consapevoli di

31
00:02:14,439 --> 00:02:19,724
un approccio per fare lo sviluppo di applicazioni chiamato sviluppo test-driven.

32
00:02:19,724 --> 00:02:26,155
Nello sviluppo basato su test, come puoi capire dal nome stesso,

33
00:02:26,155 --> 00:02:29,229
significa che prima scrivi test automatici per

34
00:02:29,229 --> 00:02:33,389
tutte le funzionalità che desideri implementare all'interno dell'applicazione.

35
00:02:33,389 --> 00:02:35,004
Quindi prima arriva il test,

36
00:02:35,004 --> 00:02:39,180
in seguito scrivi il codice dell'applicazione per superare il test.

37
00:02:39,180 --> 00:02:44,634
Quindi il test stesso specifica quale funzionalità si desidera implementare.

38
00:02:44,634 --> 00:02:47,840
Successivamente scrivi il codice per implementare tale funzionalità.

39
00:02:47,840 --> 00:02:50,165
Poiché hai già il test in atto,

40
00:02:50,165 --> 00:02:58,150
puoi testare per vedere se l'implementazione che fai soddisfa il test o meno.

41
00:02:58,150 --> 00:03:04,735
Ora, naturalmente, una volta che la vostra realizzazione della vostra funzionalità soddisfa il test,

42
00:03:04,735 --> 00:03:10,919
è sempre possibile rifattorizzare il codice per rispettare i loro standard di ingegneria del software.

43
00:03:10,919 --> 00:03:12,939
Ma anche dopo,

44
00:03:12,939 --> 00:03:16,900
è possibile testare nuovamente il codice per assicurarsi che soddisfi ancora

45
00:03:16,900 --> 00:03:20,844
i requisiti specificati all'interno di

46
00:03:20,844 --> 00:03:25,914
quel test specifico che si utilizza all'interno dello sviluppo basato su test.

47
00:03:25,914 --> 00:03:28,659
Quindi, in effetti, lo sviluppo guidato da test è

48
00:03:28,659 --> 00:03:32,199
un approccio molto praticabile per progettare una

49
00:03:32,199 --> 00:03:36,522
buona applicazione da zero per essere completamente testato.

50
00:03:36,522 --> 00:03:38,340
Ora, quando parliamo di test,

51
00:03:38,340 --> 00:03:42,009
puoi avvicinarti ai test da diversi aspetti.

52
00:03:42,009 --> 00:03:44,889
La prima di tutto è che se la tua applicazione

53
00:03:44,889 --> 00:03:48,534
stessa è implementata come vari pezzi,

54
00:03:48,534 --> 00:03:52,620
come componenti, come servizi, come le direttive,

55
00:03:52,620 --> 00:03:57,760
come le pipe che stai implementando all'interno dell'applicazione.

56
00:03:57,760 --> 00:04:03,120
Ciò significa che è possibile testare facilmente ognuna di queste singole unità isolate.

57
00:04:03,120 --> 00:04:06,435
Quindi è qui che i test unitari vengono alla ribalta.

58
00:04:06,435 --> 00:04:10,675
Test unitario significa che stai testando le singole unità di codice,

59
00:04:10,675 --> 00:04:13,750
assicurandoti che quella particolare singola unità

60
00:04:13,750 --> 00:04:18,759
soddisfi la funzionalità che dovrebbe supportare

61
00:04:18,759 --> 00:04:25,855
e che la funzionalità e la logica all'interno di quel pezzo di codice siano implementate correttamente.

62
00:04:25,855 --> 00:04:28,870
Ora isolare l'unità e testarlo è molto,

63
00:04:28,870 --> 00:04:35,401
molto utile capire la maggior parte dei problemi iniziali all'

64
00:04:35,401 --> 00:04:41,079
interno del tuo codice e quindi risolverli anche prima di integrare quella patch nel codice.

65
00:04:41,079 --> 00:04:44,259
Ora, una volta che inizi a integrare queste parti nel complesso,

66
00:04:44,259 --> 00:04:50,860
diventa ancora più ingombrante essere in grado di eseguire test dettagliati del tuo codice.

67
00:04:50,860 --> 00:04:55,839
Quindi, quindi, i test unitari isolati formano la prima linea

68
00:04:55,839 --> 00:05:01,029
di difesa contro i bug quando stai sviluppando la tua applicazione,

69
00:05:01,029 --> 00:05:03,904
in particolare la tua applicazione angolare.

70
00:05:03,904 --> 00:05:06,189
Ora, come vediamo con un angolare,

71
00:05:06,189 --> 00:05:10,540
abbiamo una chiara separazione tra i componenti angolari e il DOM stesso.

72
00:05:10,540 --> 00:05:13,339
Quindi all'interno di un componente, ad esempio, lì,

73
00:05:13,339 --> 00:05:16,930
la logica del tuo componente è implementata completamente

74
00:05:16,930 --> 00:05:22,101
nel codice dattiloscritto che hai implementato all'interno di un componente che file dattiloscritto.

75
00:05:22,101 --> 00:05:25,675
E poi il DOM stesso viene controllato attraverso

76
00:05:25,675 --> 00:05:29,660
il modello che hai progettato per il tuo componente angolare.

77
00:05:29,660 --> 00:05:33,475
Quindi Beta stessa, si vede la netta separazione tra i due.

78
00:05:33,475 --> 00:05:36,139
Quindi potresti semplicemente testare solo la logica del

79
00:05:36,139 --> 00:05:41,615
tuo codice componente stesso senza scrivere un modello verticale.

80
00:05:41,615 --> 00:05:47,350
Ma poi si potrebbe anche prendere in considerazione i due insieme e poi valutare questi aspetti.

81
00:05:47,350 --> 00:05:50,731
Come vedremo nell'esercizio che segue questa lezione,

82
00:05:50,731 --> 00:05:53,879
faremo entrambi questi approcci.

83
00:05:53,879 --> 00:05:56,685
Non solo, il fatto che angolare utilizzi l'

84
00:05:56,685 --> 00:06:01,910
iniezione di dipendenza significa che è possibile iniettare dipendenze simulate all'interno dell'applicazione.

85
00:06:01,910 --> 00:06:04,279
Quando dico finto, intendo, ad esempio,

86
00:06:04,279 --> 00:06:08,500
se il tuo componente dipende da un particolare servizio, puoi sempre implementare

87
00:06:08,500 --> 00:06:13,220
un servizio finto che imita il comportamento del servizio

88
00:06:13,220 --> 00:06:17,689
e quindi sostituirlo mentre stai testando il componente in modo da poter mantenere

89
00:06:17,689 --> 00:06:22,550
indipendente il componente di come il servizio è effettivamente implementato.

90
00:06:22,550 --> 00:06:27,110
Finché l'interfaccia tra il componente e il servizio è stata progettata correttamente, è

91
00:06:27,110 --> 00:06:32,045
possibile sostituire un servizio finto sul posto e comunque testare il componente.

92
00:06:32,045 --> 00:06:33,784
Lì, dal finto,

93
00:06:33,784 --> 00:06:39,470
puoi facilmente controllare ciò che viene fornito al componente dal servizio.

94
00:06:39,470 --> 00:06:43,220
Quindi questo approccio ti consente di eseguire test unitari

95
00:06:43,220 --> 00:06:47,990
in dettaglio all'interno della tua applicazione angolare.

96
00:06:47,990 --> 00:06:53,375
Questo è dove la disponibilità di framework di test come «Jasmine».

97
00:06:53,375 --> 00:06:55,459
Quindi ciò che Jasmine fornisce è

98
00:06:55,459 --> 00:07:03,110
un framework di test basato sul comportamento completamente progettato in JavaScript.

99
00:07:03,110 --> 00:07:06,170
Ora, questo framework Jasmine è un framework generale che

100
00:07:06,170 --> 00:07:09,505
è disponibile per testare qualsiasi applicazione JavaScript.

101
00:07:09,505 --> 00:07:18,565
Angular adotta Jasmine come approccio per specificare i nostri test per altre parti angolari,

102
00:07:18,565 --> 00:07:23,657
i loro componenti, i servizi e vari aspetti della nostra applicazione angolare.

103
00:07:23,657 --> 00:07:30,730
Ora, all'interno di Jasmine, Jasmine usa due cose che ti vengono in aiuto.

104
00:07:30,730 --> 00:07:33,722
Uno è l'uso di una funzione «descrivere».

105
00:07:33,722 --> 00:07:38,779
La funzione «descrivi» consente di raggruppare una serie di test e quindi

106
00:07:38,779 --> 00:07:45,110
eseguire questi test insieme come un unico gruppo di test.

107
00:07:45,110 --> 00:07:47,884
Quando scriviamo il codice nell'esercizio mi vedrai

108
00:07:47,884 --> 00:07:52,225
racchiudere una serie di test all'interno di una funzione di descrizione.

109
00:07:52,225 --> 00:07:55,389
Quindi scriviamo il nostro codice per il nostro,

110
00:07:55,389 --> 00:08:00,214
il codice Jasmine, per i nostri test angolari.

111
00:08:00,214 --> 00:08:05,171
Ora all'interno di queste funzioni «descrivi» userai anche ciò che viene chiamato come funzioni «it».

112
00:08:05,171 --> 00:08:07,550
Le funzioni «it» consentono di specificare

113
00:08:07,550 --> 00:08:11,949
singoli test che si desidera eseguire sulla propria applicazione angolare.

114
00:08:11,949 --> 00:08:17,509
Quindi è lì che mi vedrai specificare «it» e quindi specificare che

115
00:08:17,509 --> 00:08:21,185
la natura del particolare test e quindi

116
00:08:21,185 --> 00:08:25,259
progettare il codice per quel particolare test con una funzione in «it».

117
00:08:25,259 --> 00:08:29,240
Quindi, mentre progettiamo il codice nell'esercizio, cerca «descrivi» e

118
00:08:29,240 --> 00:08:33,575
«it» all'interno delle tue applicazioni di test angolari.

119
00:08:33,575 --> 00:08:37,559
Una volta progettato il test con il framework Jasmine,

120
00:08:37,559 --> 00:08:41,600
Karma è uno strumento da riga di comando basato su JavaScript

121
00:08:41,600 --> 00:08:46,174
che consente di eseguire questi test automaticamente.

122
00:08:46,174 --> 00:08:48,440
Ora, Karma insieme a Jasmine,

123
00:08:48,440 --> 00:08:53,500
consente di eseguire test per la vostra applicazione angolare.

124
00:08:53,500 --> 00:08:56,375
Ora con Karma, ciò che Karma supporta,

125
00:08:56,375 --> 00:08:59,065
è che consente di generare

126
00:08:59,065 --> 00:09:04,409
un server web all'interno del quale caricare il codice sorgente dell'applicazione e

127
00:09:04,409 --> 00:09:13,370
poi Karma utilizza un browser per eseguire i test effettivi delle varie unità.

128
00:09:13,370 --> 00:09:17,100
Quindi questo è dove quando esegui i i tuoi test usando Karma,

129
00:09:17,100 --> 00:09:19,774
vedrai Karma impilare un browser,

130
00:09:19,774 --> 00:09:26,120
se si tratta di una finestra del browser di un browser esistente o

131
00:09:26,120 --> 00:09:29,174
se useresti qualcosa chiamato PhantomJS che avvia

132
00:09:29,174 --> 00:09:32,715
un browser fantasma dietro le quinte per eseguire il test.

133
00:09:32,715 --> 00:09:35,855
Non importa, ma Karma utilizza

134
00:09:35,855 --> 00:09:40,554
il browser in un momento per eseguire il test per la tua applicazione angolare.

135
00:09:40,554 --> 00:09:43,356
Come vedrai nell'esercizio che segue,

136
00:09:43,356 --> 00:09:50,649
questo è dove se uno dei tuoi colleghi continua a insistere sul fatto che la sua implementazione di

137
00:09:50,649 --> 00:09:55,070
un particolare pezzo della tua applicazione angolare è

138
00:09:55,070 --> 00:09:59,659
corretta e continua a sottolineare il punto,

139
00:09:59,659 --> 00:10:03,110
puoi sempre progettare alcuni test usando Jasmine e

140
00:10:03,110 --> 00:10:07,081
Karma e poi eseguire i test e se i test falliscono,

141
00:10:07,081 --> 00:10:11,095
si può sempre confutare la loro argomentazione.

142
00:10:11,095 --> 00:10:12,615
Così è quando puoi voltarti,

143
00:10:12,615 --> 00:10:14,465
voltarti verso il tuo collega e dire,

144
00:10:14,465 --> 00:10:17,240
il mio Karma ha investito il tuo dogma.

145
00:10:17,240 --> 00:10:21,664
Ora, ovviamente, le tue applicazioni angolari non sono completamente prive

146
00:10:21,664 --> 00:10:26,419
del coinvolgimento del framework angolare stesso.

147
00:10:26,419 --> 00:10:29,210
Il tuo componente non può essere progettato da solo senza

148
00:10:29,210 --> 00:10:33,850
utilizzare molte delle funzionalità di libreria che angolare fornisce per te,

149
00:10:33,850 --> 00:10:39,215
sebbene alcune delle logiche di base possano essere testate indipendentemente dall'angolare.

150
00:10:39,215 --> 00:10:42,125
Quello che chiamiamo test isolati.

151
00:10:42,125 --> 00:10:44,450
Ma, sempre di più,

152
00:10:44,450 --> 00:10:46,659
scoprirai che a meno che tu non

153
00:10:46,659 --> 00:10:49,490
voglia il supporto del telaio angolare stesso

154
00:10:49,490 --> 00:10:52,565
non sarai in grado di eseguire gran parte del test delle

155
00:10:52,565 --> 00:11:00,639
tue parti angolari sia che si tratti di componenti o servizi o tubi o direttive.

156
00:11:00,639 --> 00:11:05,524
Quindi questo è dove le utilità di test angolari forniscono

157
00:11:05,524 --> 00:11:08,690
un ambiente di test che consente di

158
00:11:08,690 --> 00:11:12,384
eseguire i test unitari all'interno dell'applicazione angolare.

159
00:11:12,384 --> 00:11:18,139
Quindi le utilità di test angolari come mi vedrai usare negli esercizi,

160
00:11:18,139 --> 00:11:20,480
nel prossimo esercizio,

161
00:11:20,480 --> 00:11:27,034
ci forniranno alcune implementazioni di funzionalità angolari che usi

162
00:11:27,034 --> 00:11:33,950
all'interno dei tuoi test per impostare l'ambiente in cui puoi eseguire i loro test.

163
00:11:33,950 --> 00:11:37,319
Quindi, questo è dove l'interazione con l'ambiente angolare,

164
00:11:37,319 --> 00:11:41,404
invece di utilizzare le reali implementazioni angolari,

165
00:11:41,404 --> 00:11:45,740
si utilizzerà queste utilità di test che forniranno

166
00:11:45,740 --> 00:11:50,355
funzionalità sufficienti per consentire di eseguire i test.

167
00:11:50,355 --> 00:11:53,840
E questo è dove il TestBed che

168
00:11:53,840 --> 00:11:57,825
useremo all'interno della nostra applicazione angolare è molto, molto utile.

169
00:11:57,825 --> 00:12:02,899
Il TestBed crea essenzialmente un test angolare modulare.

170
00:12:02,899 --> 00:12:06,205
Come ti rendi conto, i tuoi componenti non esistono da soli.

171
00:12:06,205 --> 00:12:09,850
I componenti devono essere inclusi all'interno di un modulo NG.

172
00:12:09,850 --> 00:12:14,264
Ora non puoi semplicemente usare un modulo NG standard per eseguire i tuoi test.

173
00:12:14,264 --> 00:12:16,084
Quindi è qui che il TestBed,

174
00:12:16,084 --> 00:12:18,560
che è supportato dall'utilità di test angolare,

175
00:12:18,560 --> 00:12:24,549
fornisce un ambiente di modulo NG che consente di testare i loro componenti.

176
00:12:24,549 --> 00:12:25,850
Quindi, all'interno del TestBed,

177
00:12:25,850 --> 00:12:29,929
si utilizzerà qualcosa chiamato TestBed Crea Componente per creare

178
00:12:29,929 --> 00:12:36,139
un singolo componente e un'istanza del componente per eseguire i test su questo.

179
00:12:36,139 --> 00:12:37,940
E quando si fa che

180
00:12:37,940 --> 00:12:42,454
il TestBed dà accesso a qualcosa chiamato ComponentFixture,

181
00:12:42,454 --> 00:12:48,500
ComponentFixture è qualcosa che fornisce una maniglia che consente di circondare

182
00:12:48,500 --> 00:12:56,419
il componente con funzionalità sufficienti che il componente può essere testato da solo.

183
00:12:56,419 --> 00:13:00,950
Il dispositivo fornisce l'accesso al componente stesso e

184
00:13:00,950 --> 00:13:05,299
quindi anche attraverso che useremo qualcosa chiamato DebugElement.

185
00:13:05,299 --> 00:13:08,375
Mi vedrai usare questo nell'esercizio che segue.

186
00:13:08,375 --> 00:13:11,424
Il DebugElement ti dà accesso al DOM,

187
00:13:11,424 --> 00:13:16,754
ovvero il modello supportato come parte del tuo componente.

188
00:13:16,754 --> 00:13:23,899
Quindi, puoi fare manipolazioni sul DOM come fare clic sugli elementi nel DOM,

189
00:13:23,899 --> 00:13:29,315
ottenere l'accesso a un elemento DOM e quindi leggere ciò che è racchiuso

190
00:13:29,315 --> 00:13:35,600
all'interno di quegli elementi Dom e così via che ti consentirà di eseguire i test.

191
00:13:35,600 --> 00:13:37,669
Ora, prima di passare all'esercizio,

192
00:13:37,669 --> 00:13:43,250
voglio che tu sia consapevole di alcune di queste cose in modo che quando le incontreremo

193
00:13:43,250 --> 00:13:51,139
nell'esercizio stesso capirete perché sto facendo uso di ognuno di questi diversi pezzi.