1
00:00:00,120 --> 00:00:02,970
Comencemos, veamos primero una introducción a Nitaria.

2
00:00:03,030 --> 00:00:07,890
Pero antes, cuando uno comienza a desarrollar una aplicación, hay tres paso importante que hay que

3
00:00:07,890 --> 00:00:08,220
seguir.

4
00:00:08,250 --> 00:00:09,540
Primero, el diseño.

5
00:00:09,660 --> 00:00:11,460
Antes ecribir cualquier línea de código.

6
00:00:11,580 --> 00:00:14,190
Tienes que tener algo, algún esquema, algún plano.

7
00:00:14,320 --> 00:00:20,310
Bueno, igual cuando se construye una casa necesitamos un plano de cómo hacer esta casa.

8
00:00:20,580 --> 00:00:24,870
La cantidad de piezas dormitorio en programación, en desarrollo, aplicación es lo mismo.

9
00:00:24,900 --> 00:00:28,830
Tenemos que tener un diseño, un layout de como hacer.

10
00:00:28,980 --> 00:00:32,970
Por ejemplo, diagrama casos de uso para la toma requerimiento.

11
00:00:33,030 --> 00:00:34,860
Cuáles van a ser los usos de nuestra aplicación?

12
00:00:34,920 --> 00:00:36,240
Cuáles van a ser las funcionalidades?

13
00:00:36,270 --> 00:00:37,170
Requerimientos?

14
00:00:37,260 --> 00:00:37,680
En fin.

15
00:00:37,890 --> 00:00:42,660
Pero también tenemos que resolver un problema lo gigan y ghosts los datos cuáles van a ser nuestras

16
00:00:42,660 --> 00:00:45,240
clases, cómo se van a relacionar una con otra.

17
00:00:45,540 --> 00:00:51,180
En fin, tenemos que tener algo, algún diseño, algún esquema y resolver algún problema según regla

18
00:00:51,190 --> 00:00:51,730
de negocio.

19
00:00:51,960 --> 00:00:56,880
Pero bueno, luego empezamos a escribir nuestro código, a implementar nuestra programación, pero después,

20
00:00:56,940 --> 00:01:00,380
una vez que ya hemos finalizado, viene como tercera etapa, no es cierto?

21
00:01:00,390 --> 00:01:05,760
Probar nuestro código y acá tenemos mucha forma de probarlo, por ejemplo, utilizando herramienta de

22
00:01:05,760 --> 00:01:10,230
depuración de línea o simplemente escribiendo alguna validación en nuestro código.

23
00:01:10,350 --> 00:01:13,780
Una clase con el metodo main, instanciar una clase y probarla.

24
00:01:13,950 --> 00:01:19,740
Acá vamos a tener, por ejemplo, dato de entrada, dato de salida, un parámetro esperado y compararlo.

25
00:01:19,920 --> 00:01:26,100
El dato que ratón por ejemplo un método y compararnos septo la expectativa versus realidad si se cumple

26
00:01:26,310 --> 00:01:30,600
utilizando validación de nuestro código con sentencia de control con un IF.

27
00:01:30,660 --> 00:01:34,710
Por ejemplo, imprimir el resultado en la consola navegador.

28
00:01:34,830 --> 00:01:38,280
Eso sería una forma de escribir nuestras pruebas de nuestro código.

29
00:01:38,430 --> 00:01:38,700
12.

30
00:01:38,700 --> 00:01:39,450
Probar el código.

31
00:01:39,510 --> 00:01:43,410
Una etapa muy importante, pero también lo podemos probar en el navegador.

32
00:01:43,470 --> 00:01:47,700
Se están desarrollando una aplicación web si estamos trabajando con API Rest probarlo por ejemplo en

33
00:01:47,700 --> 00:01:51,570
Postman, que son herramientas especiales para testear una Pirry.

34
00:01:51,570 --> 00:01:53,760
Esto muchas alternativas y está perfecto.

35
00:01:53,790 --> 00:01:59,040
Son excelente cuando estamos desarrollando nuestra aplicación, pero cuando intentamos depurar cualquier

36
00:01:59,160 --> 00:02:02,160
error lógico, cualquier problema en caso de falla.

37
00:02:02,250 --> 00:02:06,390
Bueno, quizás esta forma son un poco más limitada y necesitamos algo un poco más robusto.

38
00:02:06,600 --> 00:02:13,350
Requieren un juicio humano, analizar el problema de forma un poco más manual y tampoco la limitación.

39
00:02:13,770 --> 00:02:16,860
Entonces necesitamos una herramienta que no agiliza un poco más el proceso.

40
00:02:17,070 --> 00:02:22,050
Por ejemplo, automatización, un sistema de reportería donde falló como falló.

41
00:02:22,170 --> 00:02:23,550
Cuáles son los métodos que fallaron?

42
00:02:23,790 --> 00:02:30,360
Y por ejemplo, que no hay la posibilidad de ejecutar varios casos de uso, escenarios posible y no

43
00:02:30,360 --> 00:02:32,280
solamente probar el ahora claro.

44
00:02:32,430 --> 00:02:34,110
Estamos desarrollando, probamos.

45
00:02:34,140 --> 00:02:35,190
Pero qué pasa el día mañana?

46
00:02:35,370 --> 00:02:38,790
Quién no asegura que nuestra aplicación va a seguir funcionando correctamente?

47
00:02:38,970 --> 00:02:44,700
No sé, en seis meses más, en un año podrían surgir nuevas actualizaciones, nuevas funcionalidades.

48
00:02:44,790 --> 00:02:46,560
Eso cambio, quizá afecten.

49
00:02:46,800 --> 00:02:52,920
Entonces tenemos que tener un plan de continuidad, de realización, de test, de esa forma que nos

50
00:02:52,920 --> 00:02:56,310
asegure que siga funcionando hoy y mañana.

51
00:02:56,460 --> 00:03:02,250
Pero bien, entre un poco más en detalle sobre la necesidad de realizar nuestra proas unitaria.

52
00:03:02,310 --> 00:03:09,540
Por ejemplo, acá tenemos parámetro de entrada input, todo código, todo método Clausen necesita datos

53
00:03:09,540 --> 00:03:10,080
de entrada.

54
00:03:10,380 --> 00:03:15,570
Según estos datos se va a realizar algún tipo de algoritmo, un fragmento de código que resuelve algo

55
00:03:15,660 --> 00:03:17,220
y devuelve un resultado.

56
00:03:17,250 --> 00:03:22,980
Entonces acá tenemos la pieza código devuelve una salida, un output input output.

57
00:03:23,340 --> 00:03:26,040
Entonces podríamos querer probar nuestra salida.

58
00:03:26,100 --> 00:03:28,710
El output con un valor esperado llega.

59
00:03:28,710 --> 00:03:32,070
Tenemos la espectativa, un valor esperado muy importante.

60
00:03:32,070 --> 00:03:34,320
Siempre en pruebas unitarias.

61
00:03:34,470 --> 00:03:40,100
Vamos a tener un dato que nosotros queremos obtener, que esperamos como resultado de un algoritmo.

62
00:03:40,260 --> 00:03:42,300
Pero finalmente podría ser otro.

63
00:03:42,450 --> 00:03:46,320
O podría ser un valor nulo, un valor mal calculado.

64
00:03:46,320 --> 00:03:46,740
Se fijan?

65
00:03:46,800 --> 00:03:48,300
Entonces tendremos que probar nuestro código.

66
00:03:48,480 --> 00:03:54,270
Por poner un ejemplo, una clase matemática con un método sumar A más B y los suma de vuelta.

67
00:03:54,480 --> 00:03:55,050
Perfecto.

68
00:03:55,290 --> 00:03:57,960
Entonces hay B son datos de prueba.

69
00:03:58,080 --> 00:04:01,020
Datos input de entrada y al final.

70
00:04:01,200 --> 00:04:07,380
Bueno, nosotros sabemos quedó más 3 e igual a 5, pero bueno, hay que probar realmente sumar devuelve

71
00:04:07,380 --> 00:04:13,890
5 y lo probamos sumar nuestra variable resultado de la suma del método sumar y lo comparamos.

72
00:04:13,890 --> 00:04:15,300
Sumar es distinto de 5.

73
00:04:15,430 --> 00:04:17,070
Bueno, ojo, si se distinto 5.

74
00:04:17,100 --> 00:04:18,000
Acá hay un problema.

75
00:04:18,090 --> 00:04:23,100
Algo pasó porque nuestro valor esperado es 5 y no podría ser distinto.

76
00:04:23,250 --> 00:04:27,150
Entonces acá podríamos implementar nuestra prueba, pero no solamente para este caso.

77
00:04:27,360 --> 00:04:31,170
Para Dei 3 podríamos tener, no sé, sumar valor en negativo.

78
00:04:31,200 --> 00:04:32,130
Qué pasa cuando 0?

79
00:04:32,160 --> 00:04:37,980
Cuando es negativo, cuando su número extremadamente grande o muy pequeño, incluso decimales?

80
00:04:38,010 --> 00:04:40,590
Quizás podríamos tener un sumar con decimales, se fijan?

81
00:04:40,590 --> 00:04:46,380
Son diferentes escenarios que podríamos testear acá tenemos uno solo, se fijan entonces al final del

82
00:04:46,380 --> 00:04:47,670
día prueba nuestro código.

83
00:04:47,730 --> 00:04:48,750
No es tan simple.

84
00:04:48,870 --> 00:04:51,990
De forma manual tendríamos que crear múltiples escenarios.

85
00:04:52,140 --> 00:04:57,720
Es decir, eso significa mucha clase con el método main y validar con un if se distinto de null, se

86
00:04:57,720 --> 00:04:59,910
distinto de cincos y distinto a otro valor.

87
00:05:00,080 --> 00:05:05,270
Esperado y así por cada escenario, incluso si es igual, no se te quiero comprar un valor si es igual

88
00:05:05,270 --> 00:05:05,690
a otro.

89
00:05:05,960 --> 00:05:12,500
Bueno, ahí es cuando Yunnie como framework toma importancia de que no solamente nos permite escribir

90
00:05:12,500 --> 00:05:16,970
nuestras pruebas, sino también nos permite escribir nuestras pruebas de forma mucho más ágil.

91
00:05:17,090 --> 00:05:23,060
En una sola clase, por ejemplo, podríamos tener múltiples y varios escenarios, incluso en una sola

92
00:05:23,060 --> 00:05:24,890
ejecución de una prueba unitaria.

93
00:05:25,040 --> 00:05:30,680
Podríamos ejecutar muchos test, muchos, no solamente uno, sino muchos escenarios, mucha clase de

94
00:05:30,680 --> 00:05:33,350
test y cada clase de test con múltiple método.

95
00:05:33,470 --> 00:05:34,610
Y tú has organizado.

96
00:05:34,790 --> 00:05:36,080
Es decir, se ejecutan.

97
00:05:36,170 --> 00:05:42,050
Si falla, bueno, no va a mostrar un sistema de reportería, un sistema de alertas.

98
00:05:42,170 --> 00:05:43,160
Qué método falló?

99
00:05:43,250 --> 00:05:44,120
En qué clase?

100
00:05:44,210 --> 00:05:48,320
Por qué ese con información muy valiosa, muy importante al desarrollador?

101
00:05:48,470 --> 00:05:53,120
Si hacemos esto de forma manual con el 7.a out, punto, print line o punto.

102
00:05:53,210 --> 00:05:58,130
Error muy manual, podremos tener cientos de clase, cientos de líneas de código y todo eso se va a

103
00:05:58,130 --> 00:06:01,460
mostrar de forma poco amistosa en la consola.

104
00:06:01,640 --> 00:06:07,370
Difícil de dibujar, difícil de analizar, difícil de saber dónde ocurrió el problema.

105
00:06:07,520 --> 00:06:13,430
Se necesita automatizar, parametrizar y tamé, como explicado, ejecuciones de planetarias continuas

106
00:06:13,490 --> 00:06:15,200
en el tiempo, no solamente la hora.

107
00:06:15,380 --> 00:06:20,000
Esto asegura que ante cualquier cambio de nuestra aplicación siga funcionando correctamente.

108
00:06:20,150 --> 00:06:26,090
Por ejemplo, si otra persona, incluso un compañero de nuestro equipo de trabajo de la empresa, más

109
00:06:26,090 --> 00:06:28,430
adelante realiza algún cambio en otro código.

110
00:06:28,550 --> 00:06:29,740
Nueva funcionalidad, no?

111
00:06:29,750 --> 00:06:30,170
Cierto?

112
00:06:30,300 --> 00:06:31,040
Bueno, qué pasa?

113
00:06:31,220 --> 00:06:31,940
Hay que probarlo.

114
00:06:32,030 --> 00:06:35,930
Y si falla significa que es actualización o cambio en el código?

115
00:06:36,020 --> 00:06:41,390
Está rompiendo algo en la funcionalidad del código que ya existía de nuestro código?

116
00:06:41,630 --> 00:06:49,220
Y este test que había escrito nuestra base unitaria lo va a detectar si o si lo va a detectar ya la

117
00:06:49,220 --> 00:06:49,760
importancia.

118
00:06:49,850 --> 00:06:55,280
Es decir, no es algo que se pueda detectar en una prueba manual implementada por nosotros en el desarrollo,

119
00:06:55,280 --> 00:06:58,190
por ejemplo, o realizando con la herramienta de debug.

120
00:06:58,310 --> 00:07:04,590
No, esto se detecta en el tiempo, ya están escrita simplemente después modificamos el código ejecutado

121
00:07:04,630 --> 00:07:05,040
las pruebas.

122
00:07:05,100 --> 00:07:08,810
Bueno, si falló, detectamos y corregimos entre paréntesis.

123
00:07:08,840 --> 00:07:14,150
Bueno, en realidad no es tanto modificar, porque como buena práctica no se recomienda tanto modificar

124
00:07:14,150 --> 00:07:16,790
el código que ya existe, sino más bien extender.

125
00:07:16,940 --> 00:07:21,260
De hecho, hay un principio en la programación orientada objeto open close.

126
00:07:21,410 --> 00:07:22,280
Abierto, cerrado.

127
00:07:22,400 --> 00:07:24,020
Abierto a la extensión.

128
00:07:24,110 --> 00:07:25,610
Heredar de clases.

129
00:07:25,700 --> 00:07:28,250
Extender, pero cerrado a la modificación.

130
00:07:28,500 --> 00:07:34,820
Claro, porque si modificamos 100 siempreviva alterar de forma directa el código que existe cuando modificamos

131
00:07:34,820 --> 00:07:35,180
algo.

132
00:07:35,270 --> 00:07:40,370
Porque ese código lo más probable que se está utilizando en algún lugar, al ser modificado de alguna

133
00:07:40,370 --> 00:07:43,310
forma podría alterar lo que ya existe.

134
00:07:43,460 --> 00:07:44,660
Podría romper otra cosa.

135
00:07:44,780 --> 00:07:46,910
Entonces siempre es bueno heredar, estender.

136
00:07:47,030 --> 00:07:49,000
Pero así todo, también podrían haber problemas.

137
00:07:49,040 --> 00:07:54,950
Y eso problema es lo que tenemos que también probar si ocurren y tomar alguna acción entonces muy importante,

138
00:07:54,950 --> 00:08:01,280
no solamente probar, ejecutar nuestros test cuando hayamos terminado de implementar o escribir nuestro

139
00:08:01,280 --> 00:08:05,690
código, no, sino también dar continuidad en la ejecución de test en el futuro.

140
00:08:05,810 --> 00:08:09,770
Y esto es lo que hace realmente fundamental para el éxito de nuestra aplicación.

141
00:08:09,950 --> 00:08:15,090
Pero bueno, vemos definiciones un poco más resumida qué son las pruebas unitarias?

142
00:08:15,260 --> 00:08:20,750
Es un proceso de examen para verificar que una pieza de código cumple con cierta regla negocios.

143
00:08:20,930 --> 00:08:24,480
Y eso es fundamental porque vamos a afirmar un resultado esperado.

144
00:08:24,620 --> 00:08:31,850
Comparamos algo esperado versus la realidad, versus el valor que realmente devolvió un método.

145
00:08:32,090 --> 00:08:35,540
Si falla, bueno, hay que revisar ese método, ver qué está pasando.

146
00:08:35,570 --> 00:08:39,020
Quizá hicimos mal un cálculo o devolvimos null.

147
00:08:39,170 --> 00:08:42,560
Nos olvidamos de hacer el retorno correcto.

148
00:08:42,620 --> 00:08:45,560
El ratón devolver la instancia, se fijan o el valor.

149
00:08:45,740 --> 00:08:46,970
Bueno, y qué es lo que unit?

150
00:08:47,210 --> 00:08:49,130
Porque acá tenemos pruebas unitarias en general.

151
00:08:49,160 --> 00:08:49,880
Pero Juny?

152
00:08:49,970 --> 00:08:50,870
Bueno, es un framework.

153
00:08:50,870 --> 00:08:55,190
Sellaba una librería que nos permite escribir y ejecutar pruebas.

154
00:08:55,320 --> 00:09:00,860
Es importante escribir y ejecutar, porque no solamente ejecutar, sino también escribirlas y de forma

155
00:09:00,860 --> 00:09:03,680
automatizada y también repetibles en el tiempo.

156
00:09:03,800 --> 00:09:09,770
Por eso ejecutar repetibles pruebas unitarias no solamente hoy, sino también mañana.

157
00:09:09,950 --> 00:09:10,270
Bien.

158
00:09:10,490 --> 00:09:10,850
Nada más.

159
00:09:10,850 --> 00:09:11,540
Por ahora.

160
00:09:11,720 --> 00:09:13,600
Y nos vemos en la siguiente clase.