1
00:00:04,773 --> 00:00:06,060
En la lección de hoy

2
00:00:06,085 --> 00:00:10,776
exploraremos una forma
de clasificar los tests.

3
00:00:10,973 --> 00:00:15,857
Hay muchas maneras de
en la clasificación de sus pruebas,

4
00:00:15,967 --> 00:00:20,343
pero una clasificación muy común
utilizada en la industria

5
00:00:20,368 --> 00:00:25,933
gira en torno a tres tipos principales
de pruebas en función de su alcance.

6
00:00:26,313 --> 00:00:33,300
Estas son las pruebas unitarias, pruebas de características,
y finalmente, las pruebas E2E.

7
00:00:34,166 --> 00:00:37,433
Vamos a discutir
estos diferentes tipos de pruebas

8
00:00:37,500 --> 00:00:41,933
y sus respectivos propósitos
en la jerarquía de pruebas.

9
00:00:43,043 --> 00:00:48,683
Las pruebas unitarias, como su nombre indica
se centran en unidades individuales de código.

10
00:00:49,133 --> 00:00:55,000
Por ejemplo, funciones individuales,
métodos, y, en el caso de los proyectos Vue,

11
00:00:55,033 --> 00:00:59,933
incluso componentes de soporte más simples
se prueban bajo pruebas unitarias.

12
00:01:00,208 --> 00:01:02,174
Cuando una prueba unitaria falla,

13
00:01:02,199 --> 00:01:07,500
el desarrollador sabrá con precisión
el punto problemático en la base de código.

14
00:01:08,997 --> 00:01:13,300
Yendo un poco más arriba,
llegamos a las pruebas de características.

15
00:01:13,652 --> 00:01:18,500
Ya no estamos hablando de
unidades individuales de código por sí mismas,

16
00:01:18,533 --> 00:01:24,267
sino de una característica específica
que queremos que cumpla la aplicación.

17
00:01:25,026 --> 00:01:29,833
Su ejecución dará lugar
en múltiples elementos de la aplicación

18
00:01:29,867 --> 00:01:31,667
interactuando entre sí.

19
00:01:32,133 --> 00:01:36,867
Estas pruebas son todavía conscientes
de algunos detalles de implementación,

20
00:01:36,940 --> 00:01:39,267
pero no tanto como las pruebas unitarias.

21
00:01:40,000 --> 00:01:43,567
Por ejemplo, incluso a nivel de pruebas de características,

22
00:01:43,567 --> 00:01:49,200
nuestras pruebas harán invocaciones
específicas para Vue.js

23
00:01:49,493 --> 00:01:51,533
a través de Vue Test Utils.

24
00:01:52,976 --> 00:01:54,767
Si una prueba de función falla,

25
00:01:54,800 --> 00:01:58,300
la retroalimentación no
necesariamente apuntará con precisión

26
00:01:58,325 --> 00:02:00,533
al trozo de código problemático,

27
00:02:00,826 --> 00:02:04,300
pero aún así
investigación debería ser necesaria,

28
00:02:04,380 --> 00:02:08,533
porque el alcance de las pruebas
es todavía algo limitado.

29
00:02:09,267 --> 00:02:12,300
Por último, tenemos las pruebas E2E.

30
00:02:12,820 --> 00:02:16,467
En este nivel,
estamos probando la aplicación como un todo,

31
00:02:16,533 --> 00:02:20,433
en una simulación completa
de las interacciones del usuario final.

32
00:02:21,127 --> 00:02:22,716
Este es el tipo de prueba

33
00:02:22,741 --> 00:02:26,833
que está en el nivel más alto
de los tres que hemos cubierto hoy.

34
00:02:27,533 --> 00:02:30,833
Al igual que tu usuario final no sabrá

35
00:02:30,900 --> 00:02:34,526
que su sitio web
se está ejecutando en Vue TypeScript,

36
00:02:34,659 --> 00:02:39,167
sus pruebas E2E
tampoco necesitan saberlo.

37
00:02:39,433 --> 00:02:43,233
Por esa razón, de todas
las tres pruebas que hemos cubierto,

38
00:02:43,266 --> 00:02:45,333
esta es la que menos sabe

39
00:02:45,367 --> 00:02:48,633
sobre la implementación
de tu aplicación.

40
00:02:49,500 --> 00:02:52,300
Dado que estos se están ejecutando
en el nivel más alto,

41
00:02:52,333 --> 00:02:56,367
si una prueba E2E falla,
la razón detrás del fallo

42
00:02:56,400 --> 00:02:59,700
podría estar en muchos lugares diferentes
a lo largo de la aplicación.

43
00:03:00,100 --> 00:03:03,756
Por esa razón, una investigación más larga
podría ser necesaria

44
00:03:03,781 --> 00:03:05,400
por parte del equipo de desarrollo.

45
00:03:06,193 --> 00:03:10,033
Cada tipo de prueba es valioso
y sirve para algo.

46
00:03:10,319 --> 00:03:12,230
Creo que una buena manera de

47
00:03:12,255 --> 00:03:16,633
para entender dónde cada uno de estos tipos
de pruebas

48
00:03:16,658 --> 00:03:18,933
es viéndolas en la práctica.

49
00:03:19,433 --> 00:03:23,633
He creado
una pequeña calculadora convertidora de peso.

50
00:03:23,900 --> 00:03:27,633
Se supone que para convertir
entre kilogramos y libras.

51
00:03:28,067 --> 00:03:33,167
Por ejemplo,
puedo convertir 100 kilogramos en libras,

52
00:03:33,760 --> 00:03:39,467
y también puedo convertir
100 libras en kilogramos.

53
00:03:41,443 --> 00:03:44,600
Como usted puede ser capaz de ver
en este conjunto de pruebas de aquí,

54
00:03:44,633 --> 00:03:48,967
Decidí que una manera para mí
de manejar estas conversiones de peso

55
00:03:49,000 --> 00:03:53,633
sería utilizar un objeto de datos
para representar el peso.

56
00:03:55,197 --> 00:03:59,033
Este objeto de datos
es simplemente una clase TypeScript.

57
00:04:00,133 --> 00:04:03,133
Pero en lo que quiero que te centres, sin embargo,

58
00:04:04,243 --> 00:04:06,633
son las pruebas unitarias que escribí aquí.

59
00:04:08,083 --> 00:04:11,697
Por ejemplo, escribí una prueba
que me probaría

60
00:04:11,722 --> 00:04:15,433
que puedo convertir
de libras a kilogramos,

61
00:04:15,860 --> 00:04:17,733
y también escribí otra prueba

62
00:04:17,767 --> 00:04:21,133
que podría proporcionar
un peso específico en kilogramos,

63
00:04:21,207 --> 00:04:26,867
y espero obtener la correcta
peso convertido en libras.

64
00:04:28,497 --> 00:04:33,733
Estas pruebas aquí son sólo para este
objeto de datos operando por sí mismo.

65
00:04:34,367 --> 00:04:36,200
Le estoy dando algunos valores

66
00:04:36,225 --> 00:04:40,933
y le pido que me devuelva
como otra unidad de peso

67
00:04:41,100 --> 00:04:44,133
y afirmando que estoy recibiendo
el valor esperado.

68
00:04:45,606 --> 00:04:47,659
En un nivel un poco más alto ahora,

69
00:04:48,033 --> 00:04:53,033
podemos mirar en las pruebas de características
que escribí para el componente vue.

70
00:04:53,432 --> 00:04:55,700
Observa que en este punto

71
00:04:55,740 --> 00:04:57,767
Estoy montando el componente vue

72
00:04:57,792 --> 00:05:00,800
e interactuando
con los diferentes controles

73
00:05:00,833 --> 00:05:03,200
que están siendo renderizados en la página.

74
00:05:04,093 --> 00:05:05,896
Así, por ejemplo, aquí,

75
00:05:05,921 --> 00:05:10,467
Estoy escribiendo en la entrada de peso
el valor de 100,

76
00:05:10,492 --> 00:05:14,000
y estoy marcando la casilla de verificación libras.

77
00:05:14,233 --> 00:05:17,700
Y entonces espero
que me devuelva un valor específico,

78
00:05:18,133 --> 00:05:20,433
en el elemento de entrada para el peso.

79
00:05:21,677 --> 00:05:26,033
Esta prueba no sabe
cómo estoy haciendo la conversión en sí,

80
00:05:26,100 --> 00:05:27,567
y esto es bueno.

81
00:05:28,459 --> 00:05:33,633
La prueba debe saber lo menos posible
sobre los detalles de la implementación.

82
00:05:34,479 --> 00:05:36,875
Clasifico esto como pruebas de características

83
00:05:36,900 --> 00:05:40,500
porque describen
características específicas

84
00:05:40,567 --> 00:05:42,633
que la aplicación necesita cumplir.

85
00:05:43,667 --> 00:05:48,463
Sin embargo, ten en cuenta
que parte de la comunidad Vue.js

86
00:05:48,488 --> 00:05:52,267
seguiría clasificando
estas pruebas como pruebas unitarias.

87
00:05:52,579 --> 00:05:54,442
Y desde esa perspectiva,

88
00:05:54,467 --> 00:05:58,867
es porque esto es probar
un componente vue aislado.

89
00:05:59,867 --> 00:06:03,667
Tiendo a no preocuparme
preocuparme demasiado por la semántica.

90
00:06:03,933 --> 00:06:07,900
Todo lo que espero aquí
es que podamos entender la idea

91
00:06:07,933 --> 00:06:10,533
detrás de lo que estoy llamando las pruebas de características.

92
00:06:12,046 --> 00:06:17,933
Por último, también quiero mostrar
algunas pruebas E2E que he escrito.

93
00:06:18,300 --> 00:06:19,900
Fíjate que aquí

94
00:06:19,967 --> 00:06:24,467
También estoy probando
historias de usuario para mi aplicación.

95
00:06:24,667 --> 00:06:30,233
Pero ahora, la prueba ni siquiera sabe
qué framework front-end estamos usando.

96
00:06:30,866 --> 00:06:33,070
Como puedes ver aquí, para ejecutar estas pruebas,

97
00:06:33,095 --> 00:06:36,933
estamos iniciando un servidor local
y abriendo un navegador.

98
00:06:38,457 --> 00:06:43,575
Y aquí, estamos visitando
una página real en nuestra aplicación

99
00:06:43,600 --> 00:06:46,663
y programáticamente
interactuando con la página

100
00:06:46,688 --> 00:06:48,467
como lo haría una persona real.

101
00:06:49,579 --> 00:06:53,533
Por ejemplo, aquí,
estoy visitando la página,

102
00:06:54,200 --> 00:06:58,433
Voy a la entrada para el peso,

103
00:06:58,567 --> 00:07:01,467
Voy a borrar la entrada, escribiendo 75,

104
00:07:01,933 --> 00:07:05,900
y luego selecciono el botón libras
y haciendo clic en él.

105
00:07:06,367 --> 00:07:13,133
Por último, estoy verificando que tengo
el peso de 165.35 libras

106
00:07:13,433 --> 00:07:14,633
en mi entrada.

107
00:07:15,600 --> 00:07:18,633
De los tres tipos de pruebas
que hemos cubierto hoy,

108
00:07:18,733 --> 00:07:23,500
este es el más lento
y más intensivo en recursos.

109
00:07:23,933 --> 00:07:25,803
Pero brilla sobre el terreno

110
00:07:25,828 --> 00:07:31,333
que está más cerca de lo que el usuario
experimentará realmente.

111
00:07:33,290 --> 00:07:37,933
La TDD puede utilizarse técnicamente
con cualquiera de estos niveles,

112
00:07:38,133 --> 00:07:43,067
pero mi patrón preferido es conducir
el comportamiento de la aplicación primero

113
00:07:43,167 --> 00:07:44,697
a través de pruebas de características.

114
00:07:45,033 --> 00:07:49,933
Cualquier recurso de ayuda que
necesarios durante el desarrollo

115
00:07:49,958 --> 00:07:53,600
puede tener su aplicación
a través de pruebas unitarias.

116
00:07:53,867 --> 00:07:57,133
Por último, las pruebas E2E son geniales

117
00:07:57,158 --> 00:07:59,933
para proteger
las historias de usuario más importantes

118
00:07:59,967 --> 00:08:02,833
una vez que las pruebas de características
ya están en su lugar.

119
00:08:04,663 --> 00:08:06,408
Mi razonamiento detrás de esto

120
00:08:06,433 --> 00:08:10,233
es que las pruebas de características
están en este punto dulce

121
00:08:10,400 --> 00:08:11,803
donde puedes escribir pruebas

122
00:08:11,833 --> 00:08:17,333
que protegen las historias de usuario sin forzar
estrategias de implementación específicas.

123
00:08:17,833 --> 00:08:21,367
También son relativamente rápidos
de ejecutar y escribir,

124
00:08:21,533 --> 00:08:25,257
y en caso de fallos,
todavía proporcionan retroalimentación

125
00:08:25,300 --> 00:08:28,401
que puede ser lo suficientemente específico
para el equipo de desarrollo

126
00:08:28,426 --> 00:08:32,133
para entender cuál es la causa
de la regresión muy rápidamente.

127
00:08:33,360 --> 00:08:38,697
Estupendo. Ahora usted sabe las diferencias
entre pruebas unitarias, de características y E2E.