1
00:00:02,939 --> 00:00:07,179
Permítanme hablar brevemente con ustedes acerca de las pruebas angulares.

2
00:00:07,179 --> 00:00:11,125
¿Cómo diseñas tus aplicaciones angulares para que sean probables?

3
00:00:11,125 --> 00:00:14,032
¿Cómo se diseñan las pruebas para su aplicación angular?

4
00:00:14,032 --> 00:00:16,359
¿Cómo ejecuta las pruebas y se asegura de que

5
00:00:16,359 --> 00:00:20,607
su aplicación angular esté satisfaciendo todas las pruebas que ha escrito

6
00:00:20,607 --> 00:00:25,210
incluso mientras está desarrollando su aplicación angular?

7
00:00:25,210 --> 00:00:27,394
Ahora aquí es donde también hablaría brevemente sobre el desarrollo impulsado por pruebas

8
00:00:27,394 --> 00:00:31,209
de aplicaciones angulares.

9
00:00:31,209 --> 00:00:37,225
Curiosamente, angular en sí mismo se ha construido desde cero para permitir las pruebas,

10
00:00:37,225 --> 00:00:40,820
para ser parte del desarrollo de su aplicación angular.

11
00:00:40,820 --> 00:00:47,844
La fuerza principal detrás angular Misko Hevery era él mismo un ingeniero de pruebas de Google y, por lo tanto,

12
00:00:47,844 --> 00:00:51,850
su influencia en el diseño angular para ser probable desde

13
00:00:51,850 --> 00:00:56,479
ground up se puede ver fácilmente en todo el marco.

14
00:00:56,479 --> 00:01:04,435
Así que, angular en sí mismo como has entendido de las conferencias y ejercicios anteriores,

15
00:01:04,435 --> 00:01:07,224
es de naturaleza modular.

16
00:01:07,224 --> 00:01:11,155
Así que los módulos de angular junto con los componentes y

17
00:01:11,155 --> 00:01:17,409
sus plantillas y luego los servicios y las tuberías y las directivas,

18
00:01:17,409 --> 00:01:23,559
significan que angular se presta fácilmente para ser probado.

19
00:01:23,559 --> 00:01:29,049
Ahora, debido a que la aplicación angular en sí está compuesta de estas diversas partes,

20
00:01:29,049 --> 00:01:32,319
puede probar cada una de esas partes en aislamiento primero

21
00:01:32,319 --> 00:01:36,719
incluso antes de que se conviertan en parte de toda la aplicación angular.

22
00:01:36,719 --> 00:01:40,820
El segundo aspecto es el mecanismo de inyección de dependencia que angular aprovecha

23
00:01:40,820 --> 00:01:45,969
para apoyar la combinación de las diversas partes de

24
00:01:45,969 --> 00:01:52,120
su aplicación angular en sí significa que puede reemplazar fácilmente las burlas

25
00:01:52,120 --> 00:01:54,340
por esas dependencias dentro de

26
00:01:54,340 --> 00:01:59,165
sus diversas partes del angular aplicación y llevar a cabo pruebas.

27
00:01:59,165 --> 00:02:01,135
He usado la palabra simulacro en,

28
00:02:01,135 --> 00:02:05,409
en la frase anterior llegará a entender

29
00:02:05,409 --> 00:02:10,194
que en un poco más de detalle y más que, diapositivas posteriores.

30
00:02:10,194 --> 00:02:14,439
Aquí es donde necesitamos ser conscientes de

31
00:02:14,439 --> 00:02:19,724
un enfoque para hacer el desarrollo de aplicaciones llamado desarrollo impulsado por pruebas.

32
00:02:19,724 --> 00:02:26,155
En el desarrollo basado en pruebas, como puede entender por el nombre en sí,

33
00:02:26,155 --> 00:02:29,229
significa que primero escribe pruebas automatizadas para

34
00:02:29,229 --> 00:02:33,389
toda la funcionalidad que desea implementar dentro de su aplicación.

35
00:02:33,389 --> 00:02:35,004
Así que primero viene la prueba,

36
00:02:35,004 --> 00:02:39,180
a partir de entonces escribes tu código de aplicación para pasar la prueba.

37
00:02:39,180 --> 00:02:44,634
Entonces, la prueba en sí especifica qué funcionalidad desea implementar.

38
00:02:44,634 --> 00:02:47,840
A partir de entonces, escribe el código para implementar esa funcionalidad.

39
00:02:47,840 --> 00:02:50,165
Dado que ya tiene la prueba en su lugar,

40
00:02:50,165 --> 00:02:58,150
puede probar para ver si la implementación que hace satisface la prueba o no.

41
00:02:58,150 --> 00:03:04,735
Ahora, por supuesto, una vez que su realización de su funcionalidad satisface la prueba,

42
00:03:04,735 --> 00:03:10,919
siempre puede refactorizar el código para cumplir con sus estándares de ingeniería de software.

43
00:03:10,919 --> 00:03:12,939
Pero incluso después de eso,

44
00:03:12,939 --> 00:03:16,900
puede volver a probar el código para asegurarse de que todavía cumple

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

46
00:03:20,844 --> 00:03:25,914
esa prueba específica que usa dentro de su desarrollo impulsado por pruebas.

47
00:03:25,914 --> 00:03:28,659
Así que, de hecho, el desarrollo impulsado por pruebas es

48
00:03:28,659 --> 00:03:32,199
un enfoque muy viable para diseñar

49
00:03:32,199 --> 00:03:36,522
buena aplicación desde cero para ser completamente probado.

50
00:03:36,522 --> 00:03:38,340
Ahora, cuando hablamos de pruebas,

51
00:03:38,340 --> 00:03:42,009
puedes abordar las pruebas desde varios aspectos diferentes.

52
00:03:42,009 --> 00:03:44,889
Lo primero y más importante es que si su aplicación

53
00:03:44,889 --> 00:03:48,534
en sí misma se implementa como varias piezas,

54
00:03:48,534 --> 00:03:52,620
como componentes, como servicios, como directivas,

55
00:03:52,620 --> 00:03:57,760
como las tuberías que está implementando dentro de su aplicación.

56
00:03:57,760 --> 00:04:03,120
Esto significa que puede probar fácilmente cada una de estas unidades individuales de forma aislada.

57
00:04:03,120 --> 00:04:06,435
Así que ahí es donde las pruebas unitarias pasan a primer plano.

58
00:04:06,435 --> 00:04:10,675
Prueba unitaria significa que está probando las unidades individuales de código,

59
00:04:10,675 --> 00:04:13,750
asegurándose de que esa unidad individual

60
00:04:13,750 --> 00:04:18,759
en particular satisfaga la funcionalidad que se supone que debe soportar,

61
00:04:18,759 --> 00:04:25,855
y que la funcionalidad y la lógica dentro de esa pieza de código se implementen correctamente.

62
00:04:25,855 --> 00:04:28,870
Ahora aislar la unidad y probarla es muy,

63
00:04:28,870 --> 00:04:35,401
muy útil para descubrir la mayoría de los problemas iniciales dentro de su,

64
00:04:35,401 --> 00:04:41,079
dentro de su código y luego solucionarlos incluso antes de integrar ese parche en el código.

65
00:04:41,079 --> 00:04:44,259
Ahora una vez que empieces a integrar estas partes en el conjunto,

66
00:04:44,259 --> 00:04:50,860
se vuelve aún más engorroso poder llevar a cabo pruebas detalladas de tu código.

67
00:04:50,860 --> 00:04:55,839
Entonces, por lo tanto, las pruebas unitarias aisladas forman la primera línea

68
00:04:55,839 --> 00:05:01,029
de defensa contra errores cuando está desarrollando su aplicación,

69
00:05:01,029 --> 00:05:03,904
específicamente su aplicación angular.

70
00:05:03,904 --> 00:05:06,189
Ahora como vemos con un angular,

71
00:05:06,189 --> 00:05:10,540
tenemos una clara separación entre los componentes angulares y el propio DOM.

72
00:05:10,540 --> 00:05:13,339
Así que dentro de un componente, por ejemplo, allí,

73
00:05:13,339 --> 00:05:16,930
la lógica de su componente se implementa completamente en

74
00:05:16,930 --> 00:05:22,101
el código mecanografiado que implementó dentro de un componente que archivos mecanografiados.

75
00:05:22,101 --> 00:05:25,675
Y luego el DOM en sí se controla a través de

76
00:05:25,675 --> 00:05:29,660
la plantilla que ha diseñado para su componente angular.

77
00:05:29,660 --> 00:05:33,475
Así que Beta en sí, se ve la clara separación entre los dos.

78
00:05:33,475 --> 00:05:36,139
Entonces simplemente podría probar la lógica de

79
00:05:36,139 --> 00:05:41,615
su código de componente en sí mismo sin escribir una plantilla vertical.

80
00:05:41,615 --> 00:05:47,350
Pero entonces también podría considerar los dos juntos y luego evaluar esos aspectos.

81
00:05:47,350 --> 00:05:50,731
Como veremos en el ejercicio que sigue a esta conferencia,

82
00:05:50,731 --> 00:05:53,879
realmente haremos ambos enfoques.

83
00:05:53,879 --> 00:05:56,685
No solo eso, el hecho de que angular use la inyección de dependencia

84
00:05:56,685 --> 00:06:01,910
significa que puede inyectar dependencias simuladas dentro de su aplicación.

85
00:06:01,910 --> 00:06:04,279
Cuando digo simulacro, quiero decir, por ejemplo,

86
00:06:04,279 --> 00:06:08,500
si su componente depende de un servicio particular, siempre puede implementar

87
00:06:08,500 --> 00:06:13,220
un servicio simulado que imita el comportamiento del servicio

88
00:06:13,220 --> 00:06:17,689
y luego reemplace en su lugar mientras está probando el componente para que pueda mantener

89
00:06:17,689 --> 00:06:22,550
su componente independiente de cómo se implementa realmente el servicio.

90
00:06:22,550 --> 00:06:27,110
Siempre y cuando la interfaz entre su componente y el servicio esté correctamente diseñada

91
00:06:27,110 --> 00:06:32,045
, puede sustituir un servicio simulado en su lugar y aún así probar su componente.

92
00:06:32,045 --> 00:06:33,784
Allí, desde el simulacro,

93
00:06:33,784 --> 00:06:39,470
puede controlar fácilmente lo que se suministra al componente desde el servicio.

94
00:06:39,470 --> 00:06:43,220
Así que este enfoque le permite hacer pruebas unitarias

95
00:06:43,220 --> 00:06:47,990
con gran detalle dentro de su aplicación angular.

96
00:06:47,990 --> 00:06:53,375
Aquí es donde la disponibilidad de marcos de prueba como «Jasmine».

97
00:06:53,375 --> 00:06:55,459
Entonces, lo que Jasmine proporciona es

98
00:06:55,459 --> 00:07:03,110
un marco de pruebas impulsado por el comportamiento que está completamente diseñado en JavaScript.

99
00:07:03,110 --> 00:07:06,170
Ahora, este marco de Jasmine es un marco general que

100
00:07:06,170 --> 00:07:09,505
está disponible para probar cualquier aplicación JavaScript.

101
00:07:09,505 --> 00:07:18,565
Angular adopta Jasmine como el enfoque para especificar nuestras pruebas para otras partes angulares,

102
00:07:18,565 --> 00:07:23,657
sus componentes, los servicios y varios aspectos de nuestra aplicación angular.

103
00:07:23,657 --> 00:07:30,730
Ahora, dentro de Jasmine, Jasmine usa dos cosas que vienen en tu ayuda.

104
00:07:30,730 --> 00:07:33,722
Uno es el uso de una función de «describir».

105
00:07:33,722 --> 00:07:38,779
La función «describe» le permite agrupar un conjunto de pruebas y luego

106
00:07:38,779 --> 00:07:45,110
ejecutar estas pruebas juntas como un solo grupo de pruebas.

107
00:07:45,110 --> 00:07:47,884
Cuando escribimos el código en el ejercicio me verás

108
00:07:47,884 --> 00:07:52,225
adjuntando un conjunto de pruebas dentro de una función de descripción.

109
00:07:52,225 --> 00:07:55,389
Luego escribimos nuestro código para nuestro,

110
00:07:55,389 --> 00:08:00,214
el código Jasmine, para nuestras pruebas angulares.

111
00:08:00,214 --> 00:08:05,171
Ahora dentro de estas funciones de «describir» también usarás lo que se llama «it» funciones.

112
00:08:05,171 --> 00:08:07,550
Las funciones «it» le permiten especificar

113
00:08:07,550 --> 00:08:11,949
pruebas individuales que desea realizar en su aplicación angular.

114
00:08:11,949 --> 00:08:17,509
Así que ahí es donde me verán especificando «eso» y luego especificarán que

115
00:08:17,509 --> 00:08:21,185
la naturaleza de la prueba en particular y luego

116
00:08:21,185 --> 00:08:25,259
diseñarán el código para esa prueba en particular con una función en «eso».

117
00:08:25,259 --> 00:08:29,240
Así que mientras diseñamos el código en el ejercicio busque el «describe» y

118
00:08:29,240 --> 00:08:33,575
el «it» dentro de sus aplicaciones de prueba angular.

119
00:08:33,575 --> 00:08:37,559
Una vez que haya diseñado la prueba con el framework Jasmine,

120
00:08:37,559 --> 00:08:41,600
Karma es una herramienta de línea de comandos basada en JavaScript

121
00:08:41,600 --> 00:08:46,174
que le permite realizar estas pruebas automáticamente.

122
00:08:46,174 --> 00:08:48,440
Ahora, Karma junto con Jasmine,

123
00:08:48,440 --> 00:08:53,500
le permite llevar a cabo pruebas para su aplicación angular.

124
00:08:53,500 --> 00:08:56,375
Ahora con Karma, lo que Karma apoya,

125
00:08:56,375 --> 00:08:59,065
es que le permite generar

126
00:08:59,065 --> 00:09:04,409
un servidor web dentro del cual usted carga el código fuente de su aplicación y

127
00:09:04,409 --> 00:09:13,370
luego Karma utiliza un navegador para llevar a cabo las pruebas reales de sus diversas unidades.

128
00:09:13,370 --> 00:09:17,100
Así que aquí es donde cuando ejecuta sus pruebas usando Karma,

129
00:09:17,100 --> 00:09:19,774
verá Karma apilando un navegador,

130
00:09:19,774 --> 00:09:26,120
si se trata de una ventana de navegador de un navegador existente o

131
00:09:26,120 --> 00:09:29,174
si usaría algo llamado PhantomJS que inicia

132
00:09:29,174 --> 00:09:32,715
un navegador fantasma detrás de las escenas para llevar a cabo la prueba.

133
00:09:32,715 --> 00:09:35,855
No importa, pero Karma utiliza

134
00:09:35,855 --> 00:09:40,554
el navegador en un momento para llevar a cabo la prueba para su aplicación angular.

135
00:09:40,554 --> 00:09:43,356
Como verá en el ejercicio que sigue,

136
00:09:43,356 --> 00:09:50,649
aquí es donde si uno de sus colegas sigue insistiendo en que su implementación de

137
00:09:50,649 --> 00:09:55,070
una pieza particular de su aplicación angular es

138
00:09:55,070 --> 00:09:59,659
correcta y sigue enfatizando el punto,

139
00:09:59,659 --> 00:10:03,110
siempre puede diseñar algunas pruebas usando Jasmine y

140
00:10:03,110 --> 00:10:07,081
Karma y luego llevar a cabo las pruebas y si las pruebas fallan,

141
00:10:07,081 --> 00:10:11,095
siempre puedes refutar su argumento.

142
00:10:11,095 --> 00:10:12,615
Así que es cuando puedes girar,

143
00:10:12,615 --> 00:10:14,465
dar la vuelta a tu colega y decir,

144
00:10:14,465 --> 00:10:17,240
mi Karma corrió sobre tu dogma.

145
00:10:17,240 --> 00:10:21,664
Ahora, por supuesto, sus aplicaciones angulares no están completamente desprovistas

146
00:10:21,664 --> 00:10:26,419
de la participación del marco angular en sí.

147
00:10:26,419 --> 00:10:29,210
Su componente no puede ser diseñado por usted mismo sin

148
00:10:29,210 --> 00:10:33,850
usando muchas de las funcionalidades de biblioteca que angular proporciona para usted,

149
00:10:33,850 --> 00:10:39,215
aunque parte de la lógica básica se puede probar independientemente de angular.

150
00:10:39,215 --> 00:10:42,125
Lo que llamamos como pruebas aisladas.

151
00:10:42,125 --> 00:10:44,450
Pero, cada vez más,

152
00:10:44,450 --> 00:10:46,659
encontrará que a menos que usted en,

153
00:10:46,659 --> 00:10:49,490
quiere que el soporte angular en sí mismo

154
00:10:49,490 --> 00:10:52,565
no será capaz de llevar a cabo gran parte de la prueba de

155
00:10:52,565 --> 00:11:00,639
sus partes angulares ya sean componentes o servicios o tuberías o directivas.

156
00:11:00,639 --> 00:11:05,524
Así que aquí es donde las utilidades de pruebas angulares proporcionan

157
00:11:05,524 --> 00:11:08,690
un entorno de prueba que le permite realizar

158
00:11:08,690 --> 00:11:12,384
las pruebas unitarias dentro de su aplicación angular.

159
00:11:12,384 --> 00:11:18,139
Así que las utilidades de pruebas angulares como me verán usando en los ejercicios,

160
00:11:18,139 --> 00:11:20,480
en el próximo ejercicio,

161
00:11:20,480 --> 00:11:27,034
nos proporcionarán ciertas implementaciones de funcionalidad angular que usa

162
00:11:27,034 --> 00:11:33,950
dentro de sus pruebas con el fin de configurar el entorno donde puede llevar a cabo sus pruebas.

163
00:11:33,950 --> 00:11:37,319
Entonces, aquí es donde la interacción con el entorno angular,

164
00:11:37,319 --> 00:11:41,404
en lugar de usar las implementaciones angulares reales,

165
00:11:41,404 --> 00:11:45,740
usará estas utilidades de prueba que proporcionarán

166
00:11:45,740 --> 00:11:50,355
funcionalidad suficiente para permitirle llevar a cabo las pruebas.

167
00:11:50,355 --> 00:11:53,840
Y aquí es donde el TestBed que vamos a utilizar

168
00:11:53,840 --> 00:11:57,825
dentro de nuestra aplicación angular es muy, muy útil.

169
00:11:57,825 --> 00:12:02,899
El TestBed esencialmente crea un modular de prueba angular.

170
00:12:02,899 --> 00:12:06,205
Como te das cuenta, tus componentes no existen por sí mismos.

171
00:12:06,205 --> 00:12:09,850
Sus componentes deben ser incluidos dentro de un módulo NG.

172
00:12:09,850 --> 00:12:14,264
Ahora no puede simplemente usar un módulo NG estándar para llevar a cabo sus pruebas.

173
00:12:14,264 --> 00:12:16,084
Así que ahí es donde TestBed,

174
00:12:16,084 --> 00:12:18,560
que es compatible con la utilidad de prueba angular,

175
00:12:18,560 --> 00:12:24,549
le proporciona un entorno de módulo NG que le permite probar sus componentes.

176
00:12:24,549 --> 00:12:25,850
Por lo tanto, dentro del TestBed,

177
00:12:25,850 --> 00:12:29,929
usará algo llamado TestBed Create Component para crear

178
00:12:29,929 --> 00:12:36,139
un componente individual y una instancia del componente para llevar a cabo las pruebas sobre eso.

179
00:12:36,139 --> 00:12:37,940
Y cuando haces eso

180
00:12:37,940 --> 00:12:42,454
el TestBed te da acceso a algo llamado ComponentFixture,

181
00:12:42,454 --> 00:12:48,500
ComponentFixture es algo que te proporciona un mango que te permite rodear

182
00:12:48,500 --> 00:12:56,419
tu componente con suficiente funcionalidad para que el componente pueda ser probado por sí mismo.

183
00:12:56,419 --> 00:13:00,950
El accesorio proporciona acceso al componente en sí y

184
00:13:00,950 --> 00:13:05,299
luego también a través de eso vamos a utilizar algo llamado el DebugElement.

185
00:13:05,299 --> 00:13:08,375
Me verán usando eso en el ejercicio que sigue.

186
00:13:08,375 --> 00:13:11,424
El DebugElement le da acceso al DOM,

187
00:13:11,424 --> 00:13:16,754
que es la plantilla que se admite como parte de su componente.

188
00:13:16,754 --> 00:13:23,899
Por lo tanto, puede hacer manipulaciones en el DOM como hacer clic en elementos en el DOM,

189
00:13:23,899 --> 00:13:29,315
obtener acceso a un elemento DOM y luego leer lo que está encerrado

190
00:13:29,315 --> 00:13:35,600
dentro de esos elementos Dom y así sucesivamente lo que le permitirá llevar a cabo las pruebas.

191
00:13:35,600 --> 00:13:37,669
Ahora, antes de continuar con el ejercicio,

192
00:13:37,669 --> 00:13:43,250
quiero que sean conscientes de algunas de estas cosas para que cuando las encontremos en

193
00:13:43,250 --> 00:13:51,139
el ejercicio mismo vean por qué estoy haciendo uso de cada una de estas diferentes piezas.