1
00:00:00,150 --> 00:00:00,480
Bienvenido.

2
00:00:00,510 --> 00:00:05,490
Continuamos con moquitos es un framework de prueba unitaria que también se complementa con Yuni.

3
00:00:05,550 --> 00:00:06,510
Bueno, esto lo vamos a hacer pues.

4
00:00:06,690 --> 00:00:12,510
Pero antes de definir bien de qué se trata Pakito y cuál es su características, sus funciones, vamos

5
00:00:12,510 --> 00:00:14,010
a entrar un poco en contexto.

6
00:00:14,100 --> 00:00:18,810
Acá tenemos la distinta capa de una típica aplicación de Java empresarial.

7
00:00:18,960 --> 00:00:19,410
Da lo mismo.

8
00:00:19,410 --> 00:00:25,770
Puede ser con Spring Framework o desarrollada con Java E o Enterprise Edition, ya sea con Starlet,

9
00:00:25,980 --> 00:00:29,390
ya va a ser de J, es F2, en fin, es JB.

10
00:00:29,730 --> 00:00:31,890
Da lo mismo, pero lo importante es que tenemos diferentes capas.

11
00:00:32,050 --> 00:00:36,600
Tenemos por un lado el controlador que se encarga de manejar las peticiones del usuario, el request,

12
00:00:36,840 --> 00:00:43,290
recibir, capturarnos y otro parámetro de entrada del usuario y también devolver una respuesta, un

13
00:00:43,290 --> 00:00:44,030
resultado.

14
00:00:44,130 --> 00:00:50,190
Pero antes de eso, antes de devolver un response al cliente, si tiene que comunicar con la lógica

15
00:00:50,190 --> 00:00:56,820
negocio, con los datos, mediante una clase servis, recuerde que un servis lo que hace manejar justamente

16
00:00:56,950 --> 00:01:00,510
lógica negocio interactuar con diferente componente.

17
00:01:00,630 --> 00:01:07,290
Por ejemplo, un dao o repository que se conecta y tiene acceso a una base dato paralizar operaciones,

18
00:01:07,290 --> 00:01:12,870
consulta, pero también puede interactuar con servicios que están en la nube o en otros servidores en

19
00:01:12,870 --> 00:01:17,280
otra aplicación y que están desplegadas por ejemplo en una arquitectura de micro servicios.

20
00:01:17,340 --> 00:01:23,520
Con Spring, por ejemplo Spring Cloud se fijan API Rest, que lo mismo son datos que vienen de forma

21
00:01:23,520 --> 00:01:28,830
remota de otra parte, o podrían ser Enterprise a Vinz, objetos que están desplegado en un servidor

22
00:01:28,830 --> 00:01:33,540
de aplicaciones objeto remoto E, j b o un webservice con SOAP.

23
00:01:33,720 --> 00:01:38,310
En fin, también utilizar un broker en Kiu como Rabbit.

24
00:01:38,520 --> 00:01:44,730
Una quitectura orientà evento, pero también son aplicaciones que están replegada en otro servidor de

25
00:01:44,730 --> 00:01:45,330
forma remota.

26
00:01:45,450 --> 00:01:50,820
Es decir, a lo que me refiero a que estos componentes, estas clases o API como le queramos llamar,

27
00:01:51,090 --> 00:01:53,850
no tenemos el control sobre su comportamiento.

28
00:01:54,030 --> 00:01:57,210
Por lo tanto, no podemos realizar pruebas unitarias de forma directa.

29
00:01:57,340 --> 00:02:02,250
Bueno, y lo importante si tengo implementando en nuestro código nuestra clase service que interactúa

30
00:02:02,250 --> 00:02:08,430
con otros componentes, es decir, tiene dependencia, pero a mí no me interesa probar o realizar un

31
00:02:08,430 --> 00:02:13,840
test de esa dependencia, lo que a mí me importa en mi código probar mi clase servis.

32
00:02:14,040 --> 00:02:19,470
Y además recuerden que con Judith организация unitaria, tal como dice el nombre prueba unitaria.

33
00:02:19,770 --> 00:02:25,680
Es decir, lo que estamos probando es un fragmento de código, una unidad de nuestro código, un método

34
00:02:25,770 --> 00:02:31,050
de una clase, por ejemplo, un comportamiento específico y no la dependencia externas y en paralelo,

35
00:02:31,170 --> 00:02:32,520
esa dependencia externa.

36
00:02:32,640 --> 00:02:38,010
Ni siquiera tenemos el código, ni siquiera tenemos acceso a mirar ese código, simplemente lo utilizamos.

37
00:02:38,100 --> 00:02:44,310
Claro, entonces tenemos que aislar nuestra pieza de prueba, nuestra prueba unitaria de todo ese código

38
00:02:44,400 --> 00:02:45,220
dependiente.

39
00:02:45,420 --> 00:02:49,680
Entonces todo el otro componente, lo otros objetos, lo puedo simular ahora, claro.

40
00:02:49,740 --> 00:02:55,560
Muy probablemente el componente que están desplegado en otra parte, en otro servidor, ya estén testeado,

41
00:02:55,740 --> 00:03:00,390
ya estén probado por el equipo esarrollo en cuestión que desarrolle su componente.

42
00:03:00,480 --> 00:03:05,190
Por lo tanto, no debería tener problema si se trata de un componente propio nuestro.

43
00:03:05,220 --> 00:03:09,330
Por ejemplo, un dado que se conecta no hace dato local un repository.

44
00:03:09,510 --> 00:03:14,200
Eso lo tenemos que probar aparte con una prueba de integración, no cierto?

45
00:03:14,240 --> 00:03:16,770
Claro, porque los datos vienen igualmente de forma externa.

46
00:03:16,800 --> 00:03:17,930
Vienen de una base dato.

47
00:03:18,160 --> 00:03:24,810
Entonces lo mismo no puedo testear y tampoco no puedo tener control sobre esos datos que están almacenados

48
00:03:24,930 --> 00:03:26,640
en una fuente externa y en más.

49
00:03:26,820 --> 00:03:28,110
Tampoco tenía mucho sentido.

50
00:03:28,200 --> 00:03:33,900
Muchas veces probar estos datos, porque hoy por hoy decir hoy realizo la prueba con los datos que están

51
00:03:34,020 --> 00:03:36,180
en esta base datos guardados.

52
00:03:36,330 --> 00:03:40,230
Pero recuerde que yuni test y todo lo que unitaria.

53
00:03:40,350 --> 00:03:46,290
La idea es que no solamente se prueba hoy, hoy en día, mientras estamos desarrollando no la idea que

54
00:03:46,290 --> 00:03:49,950
también sea una prueba continua en el día mañana en seis meses más.

55
00:03:49,980 --> 00:03:54,120
Cuando realizamos un cambio, tenemos que volver a probar que todos esos cambios que ya hemos realizado

56
00:03:54,210 --> 00:03:59,340
no a características funcione, ya sea nosotros o también puede ser otra persona del otro equipo.

57
00:03:59,340 --> 00:04:03,930
Desarrollo da lo mismo, no va a afectar a nuestro código decir que nuestro código no se rompa, entonces

58
00:04:03,930 --> 00:04:09,420
tenemos que continuar probando nuestra aplicación y por supuesto, los datos de la base de datos son

59
00:04:09,420 --> 00:04:12,120
dinámicos, van cambiando, puede que un registro no exista.

60
00:04:12,120 --> 00:04:15,480
Se fija entonces, obviamente, y es muy probable que vaya a fallar.

61
00:04:15,630 --> 00:04:17,960
Hoy por hoy esos datos existen.

62
00:04:17,970 --> 00:04:24,360
Lo pruebo en mi etapa de desarrollo, va a funcionar, va a pasar la prueba, pero mañana esos datos

63
00:04:24,360 --> 00:04:26,010
cambian, varían, no son estáticos.

64
00:04:26,010 --> 00:04:26,940
Entonces va a fallar.

65
00:04:27,030 --> 00:04:32,430
No es una fuente, se podría decir como fidedigna, confiable para probar nuestro dato.

66
00:04:32,610 --> 00:04:38,020
Entonces, por eso todos estos datos e información que vienen de fuentes externa lo tenemos que simular,

67
00:04:38,040 --> 00:04:39,300
simular su comportamiento.

68
00:04:39,450 --> 00:04:43,720
Bueno, y ahí es donde entra Mosquito, entonces Mosquito se encarga.

69
00:04:43,830 --> 00:04:50,970
Y acá entramos a esta segunda parte de dar comportamiento deseado a un objeto real, pero simular nuestro

70
00:04:50,970 --> 00:04:51,300
objeto.

71
00:04:51,450 --> 00:04:56,730
En realidad no estamos trabajando con una instancia real que va a invocar un método en el repository

72
00:04:57,060 --> 00:04:59,520
o en nuestro cliente.

73
00:05:00,330 --> 00:05:06,510
Por ejemplo, si estamos trabajando con Sprint, un resto en plait se fijan, no, lo que hace es detener

74
00:05:06,630 --> 00:05:13,680
esa invocación del método y en vez de eso le damos o se asigna un comportamiento deseado en un entorno

75
00:05:13,680 --> 00:05:16,770
controlado y específico, en un contexto de prueba.

76
00:05:16,890 --> 00:05:23,370
Y así podemos tener varios contextos de pruebas, datos e información que queremos probar.

77
00:05:23,550 --> 00:05:27,500
Por ejemplo, para un mismo objeto simulado, para un mismo Mok.

78
00:05:27,660 --> 00:05:33,390
Bueno, entonces moquitos al final es un framework de unitarias que nos permite crear objetos simulados.

79
00:05:33,660 --> 00:05:34,740
Se le conoce como Mok.

80
00:05:34,920 --> 00:05:40,920
Bueno, y también cuando trabajamos con moquitos tenemos que preparar nuestro entorno de prueba.

81
00:05:41,100 --> 00:05:41,630
Por ejemplo.

82
00:05:41,720 --> 00:05:41,910
Bueno.

83
00:05:42,030 --> 00:05:46,800
La clase servi va a tener dependencia y otras dependencias se van a comunicar con fuentes externas para

84
00:05:46,800 --> 00:05:47,550
obtener los datos.

85
00:05:47,730 --> 00:05:54,300
El preparar este contexto y su comportamiento y simular estos objetos se le conoce como el dado que

86
00:05:54,420 --> 00:05:54,840
entonces.

87
00:05:54,870 --> 00:05:58,770
Dado algún contexto vamos a invocar un método que no es real.

88
00:05:58,920 --> 00:06:01,350
Que su comportamiento es preparado simulado.

89
00:06:01,470 --> 00:06:03,000
Entonces es el cuando.

90
00:06:03,150 --> 00:06:05,910
Cuando invocamos llevémoslos métodos.

91
00:06:06,000 --> 00:06:12,480
Entonces realizamos las evaluaciones, los acerc con ese comportamiento que le dimos a este objeto simulado.

92
00:06:12,660 --> 00:06:18,120
No necesitamos trabajar con objetos reales, aparte que necesitamos que la aprobaciÃn inmediata sean

93
00:06:18,120 --> 00:06:18,600
rápida.

94
00:06:18,690 --> 00:06:23,160
Y si estamos trabajando con una API, por ejemplo, que se comunica con un servidor, es decir, biertas

95
00:06:23,160 --> 00:06:28,590
con una base de datos, se fijan, toma su tiempo extra en obtener los datos, en comunicarse y también

96
00:06:28,710 --> 00:06:31,740
ese otro tema que queremos evitar, lo mismo que lo hace rato.

97
00:06:31,980 --> 00:06:37,590
También toma un tiempo, muy poco, pero toma su tiempo en comunicación con las EATO.

98
00:06:37,890 --> 00:06:41,970
Si la consulta es muy pesada, se fijan y va a estar ahí procesando la información.

99
00:06:42,060 --> 00:06:47,860
Un buen rato solamente para realizar los test y no la idea que los test sean agile, que sean rápido

100
00:06:47,860 --> 00:06:49,020
y que sean continuos.

101
00:06:49,170 --> 00:06:53,460
Y todo esto apunta a un desarrollo de pruebas que está orientado al comportamiento que se le conoce.

102
00:06:53,460 --> 00:07:02,610
Como ve desde Vijay Beard, Traven de Mento V BD y por supuesto TDD también se desarrollo impulsado

103
00:07:02,670 --> 00:07:08,040
a unitaria, claro, porque podríamos dejar para después la implementación por ejemplo de esta dependencia

104
00:07:08,190 --> 00:07:14,670
del repositorio del DAO de clase aseso dato o de alguna interfaz que se comunica con una Pirry es un

105
00:07:14,670 --> 00:07:15,390
servicio REST.

106
00:07:15,480 --> 00:07:20,730
Se fijan esta implementación para después después implementamos, ahora no dedicamos a probar y podríamos

107
00:07:20,730 --> 00:07:22,350
simular ese comportamiento.

108
00:07:22,500 --> 00:07:23,970
Entonces también sería TDD.

109
00:07:24,120 --> 00:07:29,070
Entonces recuerden, cuando trabajamos con moquitos estamos trabajando también orientar comportamiento,

110
00:07:29,070 --> 00:07:33,990
ya que estamos modificando el comportamiento y lo estamos simulando estos objetos reales y entonces

111
00:07:33,990 --> 00:07:39,000
trabajamos con tres partes con el dado que con el cuándo y con el entonces.

112
00:07:39,060 --> 00:07:46,320
El dado que recuerden preparamos nuestro contexto dependencia, parámetro de entradas o input, el cuándo,

113
00:07:46,380 --> 00:07:51,750
cuando finalmente invocamos este método que queremos probar con estos datos o comportamiento simulado,

114
00:07:51,900 --> 00:07:58,320
entonces validamos si pasa o no pasa la prueba, por ejemplo con los acertijos, el assert y cual de

115
00:07:58,320 --> 00:08:05,220
yuni hacer truo y también co verifi que es propio de Makita, que después vamos a ver que para verificar

116
00:08:05,220 --> 00:08:10,770
si se embocó se llamó o se ejecutó un método que estamos simulando también.

117
00:08:10,780 --> 00:08:16,290
Después vamos a saber que no solamente tenemos los mock dentro de moquitos, también tenemos los espías.

118
00:08:16,350 --> 00:08:21,240
Los Speight es un híbrido entre el objeto real y un mock.

119
00:08:21,480 --> 00:08:26,460
De cierta forma podemos simular algún comportamiento, algunos métodos, pero también podemos invocar

120
00:08:26,490 --> 00:08:27,300
métodos reales.

121
00:08:27,510 --> 00:08:31,290
Al final es como un híbrido, pero eso después lo vamos a ver y lo que sea que utilizar con cuidado

122
00:08:31,440 --> 00:08:37,920
con no siempre se utiliza en la mayoría de los scenario, preferiblemente utilizar mock objeto simulado.

123
00:08:38,220 --> 00:08:41,340
Lo dejamos hasta acá y continuamos en la siguiente clase.