Bienvenido.
Continuamos con moquitos es un framework de prueba unitaria que también se complementa con Yuni.
Bueno, esto lo vamos a hacer pues.
Pero antes de definir bien de qué se trata Pakito y cuál es su características, sus funciones, vamos
a entrar un poco en contexto.
Acá tenemos la distinta capa de una típica aplicación de Java empresarial.
Da lo mismo.
Puede ser con Spring Framework o desarrollada con Java E o Enterprise Edition, ya sea con Starlet,
ya va a ser de J, es F2, en fin, es JB.
Da lo mismo, pero lo importante es que tenemos diferentes capas.
Tenemos por un lado el controlador que se encarga de manejar las peticiones del usuario, el request,
recibir, capturarnos y otro parámetro de entrada del usuario y también devolver una respuesta, un
resultado.
Pero antes de eso, antes de devolver un response al cliente, si tiene que comunicar con la lógica
negocio, con los datos, mediante una clase servis, recuerde que un servis lo que hace manejar justamente
lógica negocio interactuar con diferente componente.
Por ejemplo, un dao o repository que se conecta y tiene acceso a una base dato paralizar operaciones,
consulta, pero también puede interactuar con servicios que están en la nube o en otros servidores en
otra aplicación y que están desplegadas por ejemplo en una arquitectura de micro servicios.
Con Spring, por ejemplo Spring Cloud se fijan API Rest, que lo mismo son datos que vienen de forma
remota de otra parte, o podrían ser Enterprise a Vinz, objetos que están desplegado en un servidor
de aplicaciones objeto remoto E, j b o un webservice con SOAP.
En fin, también utilizar un broker en Kiu como Rabbit.
Una quitectura orientÃ evento, pero también son aplicaciones que están replegada en otro servidor de
forma remota.
Es decir, a lo que me refiero a que estos componentes, estas clases o API como le queramos llamar,
no tenemos el control sobre su comportamiento.
Por lo tanto, no podemos realizar pruebas unitarias de forma directa.
Bueno, y lo importante si tengo implementando en nuestro código nuestra clase service que interactúa
con otros componentes, es decir, tiene dependencia, pero a mí no me interesa probar o realizar un
test de esa dependencia, lo que a mí me importa en mi código probar mi clase servis.
Y además recuerden que con Judith организация unitaria, tal como dice el nombre prueba unitaria.
Es decir, lo que estamos probando es un fragmento de código, una unidad de nuestro código, un método
de una clase, por ejemplo, un comportamiento específico y no la dependencia externas y en paralelo,
esa dependencia externa.
Ni siquiera tenemos el código, ni siquiera tenemos acceso a mirar ese código, simplemente lo utilizamos.
Claro, entonces tenemos que aislar nuestra pieza de prueba, nuestra prueba unitaria de todo ese código
dependiente.
Entonces todo el otro componente, lo otros objetos, lo puedo simular ahora, claro.
Muy probablemente el componente que están desplegado en otra parte, en otro servidor, ya estén testeado,
ya estén probado por el equipo esarrollo en cuestión que desarrolle su componente.
Por lo tanto, no debería tener problema si se trata de un componente propio nuestro.
Por ejemplo, un dado que se conecta no hace dato local un repository.
Eso lo tenemos que probar aparte con una prueba de integración, no cierto?
Claro, porque los datos vienen igualmente de forma externa.
Vienen de una base dato.
Entonces lo mismo no puedo testear y tampoco no puedo tener control sobre esos datos que están almacenados
en una fuente externa y en más.
Tampoco tenía mucho sentido.
Muchas veces probar estos datos, porque hoy por hoy decir hoy realizo la prueba con los datos que están
en esta base datos guardados.
Pero recuerde que yuni test y todo lo que unitaria.
La idea es que no solamente se prueba hoy, hoy en día, mientras estamos desarrollando no la idea que
también sea una prueba continua en el día mañana en seis meses más.
Cuando realizamos un cambio, tenemos que volver a probar que todos esos cambios que ya hemos realizado
no a características funcione, ya sea nosotros o también puede ser otra persona del otro equipo.
Desarrollo da lo mismo, no va a afectar a nuestro código decir que nuestro código no se rompa, entonces
tenemos que continuar probando nuestra aplicación y por supuesto, los datos de la base de datos son
dinámicos, van cambiando, puede que un registro no exista.
Se fija entonces, obviamente, y es muy probable que vaya a fallar.
Hoy por hoy esos datos existen.
Lo pruebo en mi etapa de desarrollo, va a funcionar, va a pasar la prueba, pero mañana esos datos
cambian, varían, no son estáticos.
Entonces va a fallar.
No es una fuente, se podría decir como fidedigna, confiable para probar nuestro dato.
Entonces, por eso todos estos datos e información que vienen de fuentes externa lo tenemos que simular,
simular su comportamiento.
Bueno, y ahí es donde entra Mosquito, entonces Mosquito se encarga.
Y acá entramos a esta segunda parte de dar comportamiento deseado a un objeto real, pero simular nuestro
objeto.
En realidad no estamos trabajando con una instancia real que va a invocar un método en el repository
o en nuestro cliente.
Por ejemplo, si estamos trabajando con Sprint, un resto en plait se fijan, no, lo que hace es detener
esa invocación del método y en vez de eso le damos o se asigna un comportamiento deseado en un entorno
controlado y específico, en un contexto de prueba.
Y así podemos tener varios contextos de pruebas, datos e información que queremos probar.
Por ejemplo, para un mismo objeto simulado, para un mismo Mok.
Bueno, entonces moquitos al final es un framework de unitarias que nos permite crear objetos simulados.
Se le conoce como Mok.
Bueno, y también cuando trabajamos con moquitos tenemos que preparar nuestro entorno de prueba.
Por ejemplo.
Bueno.
La clase servi va a tener dependencia y otras dependencias se van a comunicar con fuentes externas para
obtener los datos.
El preparar este contexto y su comportamiento y simular estos objetos se le conoce como el dado que
entonces.
Dado algún contexto vamos a invocar un método que no es real.
Que su comportamiento es preparado simulado.
Entonces es el cuando.
Cuando invocamos llevémoslos métodos.
Entonces realizamos las evaluaciones, los acerc con ese comportamiento que le dimos a este objeto simulado.
No necesitamos trabajar con objetos reales, aparte que necesitamos que la aprobaciÃn inmediata sean
rápida.
Y si estamos trabajando con una API, por ejemplo, que se comunica con un servidor, es decir, biertas
con una base de datos, se fijan, toma su tiempo extra en obtener los datos, en comunicarse y también
ese otro tema que queremos evitar, lo mismo que lo hace rato.
También toma un tiempo, muy poco, pero toma su tiempo en comunicación con las EATO.
Si la consulta es muy pesada, se fijan y va a estar ahí procesando la información.
Un buen rato solamente para realizar los test y no la idea que los test sean agile, que sean rápido
y que sean continuos.
Y todo esto apunta a un desarrollo de pruebas que está orientado al comportamiento que se le conoce.
Como ve desde Vijay Beard, Traven de Mento V BD y por supuesto TDD también se desarrollo impulsado
a unitaria, claro, porque podríamos dejar para después la implementación por ejemplo de esta dependencia
del repositorio del DAO de clase aseso dato o de alguna interfaz que se comunica con una Pirry es un
servicio REST.
Se fijan esta implementación para después después implementamos, ahora no dedicamos a probar y podríamos
simular ese comportamiento.
Entonces también sería TDD.
Entonces recuerden, cuando trabajamos con moquitos estamos trabajando también orientar comportamiento,
ya que estamos modificando el comportamiento y lo estamos simulando estos objetos reales y entonces
trabajamos con tres partes con el dado que con el cuándo y con el entonces.
El dado que recuerden preparamos nuestro contexto dependencia, parámetro de entradas o input, el cuándo,
cuando finalmente invocamos este método que queremos probar con estos datos o comportamiento simulado,
entonces validamos si pasa o no pasa la prueba, por ejemplo con los acertijos, el assert y cual de
yuni hacer truo y también co verifi que es propio de Makita, que después vamos a ver que para verificar
si se embocó se llamó o se ejecutó un método que estamos simulando también.
Después vamos a saber que no solamente tenemos los mock dentro de moquitos, también tenemos los espías.
Los Speight es un híbrido entre el objeto real y un mock.
De cierta forma podemos simular algún comportamiento, algunos métodos, pero también podemos invocar
métodos reales.
Al final es como un híbrido, pero eso después lo vamos a ver y lo que sea que utilizar con cuidado
con no siempre se utiliza en la mayoría de los scenario, preferiblemente utilizar mock objeto simulado.
Lo dejamos hasta acá y continuamos en la siguiente clase.