1
00:00:00,000 --> 00:00:04,307
[MUSIC]

2
00:00:04,307 --> 00:00:09,895
En la anterior conferencia y ejercicio que siguió a la conferencia,

3
00:00:09,895 --> 00:00:14,330
hemos examinado el uso de pruebas unitarias en Angular.

4
00:00:14,330 --> 00:00:18,920
Hemos visto cómo las diferentes partes de nuestra aplicación angular, los componentes,

5
00:00:18,920 --> 00:00:26,420
los servicios, las directivas, las tuberías se pueden probar utilizando pruebas unitarias.

6
00:00:26,420 --> 00:00:27,000
Pero, por supuesto, las pruebas unitarias

7
00:00:27,000 --> 00:00:32,550
no revelan todo sobre la interacción entre los componentes.

8
00:00:32,550 --> 00:00:37,090
Ahí es donde las estrategias de prueba de extremo a extremo nos permiten

9
00:00:37,090 --> 00:00:42,480
ver que toda la aplicación funciona como una sola unidad.

10
00:00:42,480 --> 00:00:49,200
Así que en esta conferencia, vamos a examinar el uso de pruebas de extremo a extremo y

11
00:00:49,200 --> 00:00:54,950
qué papel juegan en la estrategia general de pruebas para nuestras aplicaciones angulares.

12
00:00:54,950 --> 00:01:01,592
En el siguiente ejercicio, veremos brevemente cómo podemos llevar a cabo pruebas

13
00:01:01,592 --> 00:01:06,160
end-to-end para nuestra aplicación Angular, utilizando una herramienta llamada Transportador.

14
00:01:08,110 --> 00:01:13,710
Como ya hemos aprendido en la conferencia anterior, las pruebas unitarias

15
00:01:13,710 --> 00:01:19,650
nos brindan una maravillosa oportunidad para probar nuestras unidades en aislamiento.

16
00:01:19,650 --> 00:01:25,105
Asegurándose de que nuestras unidades realizan lo que se espera que realicen,

17
00:01:25,105 --> 00:01:29,446
su lógica es correcta, y la interacción entre el componente y

18
00:01:29,446 --> 00:01:33,720
su plantilla está bien establecida.

19
00:01:33,720 --> 00:01:38,230
Pero, por supuesto, las pruebas unitarias no

20
00:01:38,230 --> 00:01:43,720
completan la imagen completa de cómo funciona una aplicación angular típica.

21
00:01:43,720 --> 00:01:47,807
No tiene unidades individuales trabajando aisladamente.

22
00:01:47,807 --> 00:01:51,293
En su lugar, sus componentes interactúan con los servicios.

23
00:01:51,293 --> 00:01:53,573
Los componentes pueden hacer uso de tipos.

24
00:01:53,573 --> 00:01:58,503
Los servicios, a su vez, interactuarán con el backend para recuperar los datos.

25
00:01:58,503 --> 00:02:02,300
Y luego el componente mismo será responsable de

26
00:02:02,300 --> 00:02:06,670
renderizar las vistas usando las plantillas para el componente.

27
00:02:06,670 --> 00:02:13,686
Entonces, ¿cómo funciona todo este conjunto de unidades?

28
00:02:13,686 --> 00:02:18,485
¿Y cómo nos aseguramos de que el trabajo conjunto de estas unidades

29
00:02:18,485 --> 00:02:22,202
esté completamente libre de problemas?

30
00:02:22,202 --> 00:02:26,931
Así que ahí es donde las pruebas de extremo a extremo y en el camino, las pruebas de integración

31
00:02:26,931 --> 00:02:32,780
nos ayudan a cubrir este tipo de escenarios.

32
00:02:32,780 --> 00:02:39,190
Por supuesto, las pruebas unitarias juegan un papel importante en la estrategia general de pruebas.

33
00:02:39,190 --> 00:02:42,133
Pero sin hacer pruebas de extremo a extremo,

34
00:02:42,133 --> 00:02:47,852
no podemos estar completamente seguros de que nuestra aplicación esté funcionando como se esperaba.

35
00:02:47,852 --> 00:02:52,697
Una cosa que debo enfatizar es que las pruebas unitarias son rápidas y

36
00:02:52,697 --> 00:02:56,790
muy fáciles de repetir y se pueden hacer varias veces.

37
00:02:56,790 --> 00:03:01,861
Las pruebas de integración y las pruebas de extremo a extremo son lentas, por lo que se utilizan

38
00:03:01,861 --> 00:03:08,390
solo con moderación para confirmar que su aplicación está funcionando como se esperaba.

39
00:03:08,390 --> 00:03:11,830
Así que cuando miramos nuestra estrategia general de pruebas,

40
00:03:11,830 --> 00:03:16,070
podemos considerarla como organizada en forma de pirámide.

41
00:03:16,070 --> 00:03:19,940
En la parte inferior de la pirámide, ocupando toda la base y

42
00:03:19,940 --> 00:03:25,251
formando la base de nuestra estrategia general de pruebas, están las pruebas unitarias.

43
00:03:26,710 --> 00:03:31,790
Como hemos aprendido, las pruebas unitarias nos permiten probar las unidades individuales en aislamiento,

44
00:03:31,790 --> 00:03:35,460
asegurándonos de que su lógica y

45
00:03:35,460 --> 00:03:39,970
la forma en que funcionan estas unidades es correcta.

46
00:03:39,970 --> 00:03:42,890
Y estas pruebas pueden repetirse con mucha frecuencia.

47
00:03:42,890 --> 00:03:48,040
Y de hecho, debe repetirse con frecuencia para asegurarse de que las unidades individuales

48
00:03:48,040 --> 00:03:49,610
están funcionando como se esperaba.

49
00:03:50,630 --> 00:03:57,850
Por supuesto, en un segundo nivel de esta estrategia serían las pruebas de integración.

50
00:03:57,850 --> 00:04:02,600
¿Cómo un pequeño grupo de unidades trabaja juntos en

51
00:04:02,600 --> 00:04:07,680
implementando lo que sea necesario que hagan esos grupos de unidades?

52
00:04:07,680 --> 00:04:12,460
Así que tal vez podríamos probar un componente junto con

53
00:04:12,460 --> 00:04:17,730
sus servicios para ver cómo ocurre el flujo de información entre ellos.

54
00:04:17,730 --> 00:04:22,880
Pero en la parte superior de esta pirámide está de extremo a extremo pruebas donde

55
00:04:22,880 --> 00:04:25,320
nos fijamos en la aplicación general.

56
00:04:25,320 --> 00:04:29,880
Y qué tan bien está funcionando la aplicación general y

57
00:04:29,880 --> 00:04:32,890
cumple con sus requisitos esperados.

58
00:04:32,890 --> 00:04:36,990
Así que ahí es donde vemos el uso de pruebas de extremo a extremo.

59
00:04:36,990 --> 00:04:42,680
Como ya puede esperar con este diagrama, las pruebas de extremo a extremo son lentas.

60
00:04:42,680 --> 00:04:48,584
Y por lo tanto, no realizamos pruebas de extremo a extremo con mucha frecuencia, en su lugar, la prueba de unidad

61
00:04:48,584 --> 00:04:55,412
constituye la estrategia principal para nuestras pruebas de nuestra aplicación angular.

62
00:04:55,412 --> 00:05:02,149
Las pruebas de extremo a extremo contribuyen en el panorama general, pero no se hacen tan

63
00:05:02,149 --> 00:05:08,021
con frecuencia, pero siguen siendo una parte esencial de nuestra estrategia de pruebas.

64
00:05:08,021 --> 00:05:10,852
Entonces, ¿cómo llevamos a cabo pruebas de extremo a extremo?

65
00:05:10,852 --> 00:05:15,210
Hablemos brevemente de las herramientas que están disponibles para nosotros.

66
00:05:15,210 --> 00:05:18,199
El entorno de pruebas angulares para pruebas de extremo a extremo

67
00:05:18,199 --> 00:05:23,740
es compatible con una herramienta llamada Transportador.

68
00:05:23,740 --> 00:05:27,930
¿Quién dice que los frikis no tienen sentido del humor?

69
00:05:27,930 --> 00:05:30,950
Transportador, Angular, ahí tienes.

70
00:05:30,950 --> 00:05:33,450
Entonces, ¿qué es exactamente Transportador?

71
00:05:33,450 --> 00:05:37,500
Transportador es, como es de esperar, un programa de nodos.

72
00:05:37,500 --> 00:05:40,940
Así que esto nos permite llevar a cabo pruebas de extremo a extremo.

73
00:05:40,940 --> 00:05:45,510
Así que Transportador ejecuta las pruebas contra su aplicación.

74
00:05:45,510 --> 00:05:49,800
Así que Transportador carga su aplicación en un navegador e interactúa con

75
00:05:49,800 --> 00:05:54,570
la aplicación al igual que un usuario real interactuará con su aplicación.

76
00:05:54,570 --> 00:05:59,160
Así que estamos buscando interactuar con su aplicación,

77
00:05:59,160 --> 00:06:03,410
aunque programáticamente, pero realizando el tipo de operaciones que

78
00:06:03,410 --> 00:06:07,500
un usuario típico realizará como hacer clic en enlaces, rellenar formularios.

79
00:06:07,500 --> 00:06:13,110
Enviar formularios, navegar a diferentes partes de su solicitud y así sucesivamente.

80
00:06:13,110 --> 00:06:18,310
Así que aquí es donde Transportador aprovecha el uso de un WebDriver para controlar los navegadores

81
00:06:18,310 --> 00:06:23,980
en los que se pueden llevar a cabo las pruebas.

82
00:06:23,980 --> 00:06:27,570
Uno de esos marcos de aplicación se llama Selenium Framework,

83
00:06:27,570 --> 00:06:31,720
que se usa para hacer pruebas automatizadas dentro de los navegadores.

84
00:06:31,720 --> 00:06:36,021
Si estás usando Chrome como parte de tu estrategia de prueba o Firefox,

85
00:06:36,021 --> 00:06:39,119
entonces puedes usar lo que se llama conexión directa.

86
00:06:39,119 --> 00:06:43,502
que está disponible a través de un transportador para conectarse directamente a estos navegadores y

87
00:06:43,502 --> 00:06:45,828
realizar pruebas dentro de esos navegadores.

88
00:06:45,828 --> 00:06:50,273
Ahora, las propias pruebas aprovechan el marco de ajuste para

89
00:06:50,273 --> 00:06:51,790
expresando la prueba.

90
00:06:51,790 --> 00:06:55,450
Así que aún vería al usuario describir un int y

91
00:06:55,450 --> 00:06:58,810
antes de cada uno que haya visto con pruebas unitarias.

92
00:06:58,810 --> 00:07:04,332
Excepto que ahora, vamos a aprovechar el soporte del transportador para

93
00:07:04,332 --> 00:07:09,119
siendo capaz de generar interacciones reales como el usuario con nuestra aplicación

94
00:07:09,119 --> 00:07:11,157
usando código.

95
00:07:11,157 --> 00:07:15,363
Así que eso es lo que aprenderemos en el ejercicio que sigue a esta particular conferencia

96
00:07:15,363 --> 00:07:15,979
.

97
00:07:15,979 --> 00:07:21,324
Vamos a hacer uso de Transportador y escribir nuestras estrategias de prueba de extremo a extremo.

98
00:07:21,324 --> 00:07:24,815
Y, por supuesto, aproveche el soporte de la CLI angular para

99
00:07:24,815 --> 00:07:29,983
llevando a cabo pruebas de extremo a extremo en el ejercicio que sigue a esta conferencia.

100
00:07:29,983 --> 00:07:32,969
[MÚSICA]