Yo sé que con el título de esta clase, tal vez muchas personas no están interesadas en verlo, pero
la parte del testing es sumamente importante para el desarrollo de aplicaciones y también es sumamente
importante para el desarrollo y creación de nuestras imágenes.
Por qué?
Porque el objetivo es que cuando nosotros creamos nuestra imagen, obviamente esta imagen también debería
estar probada, porque el código fuente que yo estoy usando para crearla debería de pasar mi testing.
Cuál es el objetivo del testing automático de las pruebas automáticas?
Asegurarnos de que nuestro código cumpla los objetivos en las cuales nosotros hemos escrito pruebas
automáticas.
Es decir, podemos probar la ruta crítica, podemos probar ciertas funcionalidades de la aplicación
y el objetivo es nuevamente que si alguna prueba no pasa, no deberíamos de construir la imagen porque
hay un problema.
En pocas palabras, estaríamos acarreando un problema a la versión de producción y no queremos que en
la versión de producción nos demos cuenta de que algo no funcionó bien.
Ese es el objetivo también de las pruebas automáticas, que nosotros por lo menos tengamos cierta capa
de seguridad y saber que nuestra aplicación se comporta como nosotros estamos esperando.
Claro, esto es una aplicación muy sencilla y tampoco no es un curso de testing, pero por lo menos
quiero hacer una prueba sencilla para ver el caso cuando la prueba falla o cuando alguna prueba falla
y cuándo o qué hacer cuando todo pasa bien.
Hay muchas características valiosas que vamos a aprender con esto, o sea, hacer este ejercicio.
Así que aunque más de uno de usted diga no me interesa hacer testing, por favor, acompáñeme y hagan
esto porque vamos a aprender mucho sobre Docker también al respecto.
Ok, una vez dicho eso, comencemos, Yo le voy a pedir que abramos la terminal, o sea de Windows.
Yo como bueno, imaginarán, esto es otro día.
Yo estoy grabando esta clase o este curso no lo grabo todo en un día, entonces voy a hacer un cd a
la carpeta de nuestro proyecto de nuevo Chrome Ticker.
También lo pueden hacer con la terminal integrada Visual Studio.
No hay problema, pero nuevamente quiero hacerlo de esta de este punto para que se mire claramente.
Si ustedes hacen un DIR o LSE van a ver que aquí tenemos el Docker, Phil, el package JSON y todo lo
demás.
Aquí vamos a escribir el siguiente comando npm y de instalar vamos a instalar guest espacio menos menos
menos dev.
Es decir, quiero hacer la instalación de este paquete YES que nos va a ayudar a hacer el testing en
nuestra aplicación y es una dependencia de desarrollo.
Instala 29 paquetes, bueno, 279 paquetes y hace muchas cosas en nuestros módulos de NOD.
Entonces si yo regreso a Visual Studio Code y abro el paquete de JSON, van a ver que aquí tenemos las
dependencias de YES.
Si ustedes por alguna razón lo instalaron en las dependencias normales, vuelvan a ejecutar el comando,
pero poniendo el seis dev para que lo coloque aquí.
Y realmente ustedes no quieren cambiar las dependencias manualmente?
Ok.
Si analizamos los módulos de nodos van a ver que ahora hay un montón de archivos nuevos.
Hay un montón de archivos que todo esto lo utiliza de una X o y razón.
La parte de West Machine no va decir Bueno, y esto y este montón de.
De dónde salió?
Cómo lo manejo?
Ustedes no se preocupen de esto.
Y sabe cuáles dependencias son las que necesita?
Ok, pero nuevamente son dependencias de desarrollo que no deberían de ir a el build de producción,
pero ya eso será un tema de otra clase que vamos a cubrir en esta sección, así que no se preocupen,
voy a refactorizar mi código un poco para que sea más fácil de probar, porque así es algo complicado
y la verdad es que no quiero hacer un curso de testing propiamente, entonces lo que voy a hacer es
crearme un nuevo, una nueva carpeta que se llama Task o task en plural, y adentro voy a crearme un
nuevo archivo.
Hagamos esto un poco más grande.
Y este nuevo archivo se llama como Sink db js, el cual va a ser la función que yo quiero ejecutar para
sincronizar mi base de datos o el proceso automático o uno del X cantidad de procesos automáticos,
van a copiarse la función que tenemos aquí desde estos paréntesis hasta aquí abajo, control C y voy
a crearlo por acá constante, voy a ponerle Sink.
DB Va a ser igual a una función de flecha, Abro y cierro llaves y aquí dentro saben qué?
Mejor solo copiemos lo que tenemos acá, copien esto de aquí solo el contenido de la función y la pego,
ocupo times, voy a crearme la variable times, va a ser igual a cero.
Y adicionalmente aquí voy a retornar Things.
Es decir, cuando yo hago el Sync TV y lo mandé llamar, voy a retornar la cantidad de veces que se
ha sincronizado el proceso.
Como esta es una función que yo voy a ocupar en otro archivo y me encuentro una aplicación en OUT,
vamos a hacerlo así Modulo export abren y cierran llaves.
No se les olvide poner el igual y exportamos la función de Sync Divi.
Hay varias formas de hacer esto, pero lo voy a hacer de esta manera para no tener que importar nada
más en mi proyecto.
Entonces TV es la función que voy a llamar.
Regresemos al app JS, borremos times, borremos todo el cuerpo de esta función y toda la función.
Y aquí voy a mandar a llamar Sink DB.
Nada más asegúrese de escribir esta importación porque quiero importar la función de Sync TV que viene
de Task sin DB y este inicio de la aplicación lo puedo colocar aquí arriba.
Ok, voy a grabar los cambios.
No es nada abrupto lo que yo hice.
Voy a regresar y esto no tiene nada que ver.
Ya tampoco voy a venir aquí y escribir npm run.
No, nada más npm, start.
Presionamos enter y van a ver que todo sigue funcionando exactamente igual.
Inicio de la aplicación y cada segundos cinco, diez, 15, 20.
Tenemos esta.
Este resultado.
Ok, voy a cancelarlo y si ustedes se les queda pegado, ustedes ya saben, pueden eliminar forzosamente
ese contenedor.
Miren, regresemos aquí.
Todavía no hemos hecho nada de las pruebas.
Cuál es el objetivo de las pruebas?
Digamos que lo único que yo voy a querer probar es que si yo mando a llamar esta función, yo estoy
esperando que me regrese un valor de Time.
Si yo lo llamo dos veces, entonces estaría esperando que este valor sea dos, por ejemplo.
Entonces hagamos una prueba súper sencilla.
Usualmente la parte de testing está en su carpeta independiente que se llama test y en la cual voy a
tener la misma estructura de archivos que yo tengo aquí en mi proyecto.
Técnicamente deberíamos de crear un source para mantener esto más ordenado, pero no, olvídense de
eso.
Por ahora.
Dentro de la carpeta test voy a crear otra carpeta que se llama Task Task y dentro de la carpeta Task
voy a crearme un archivo que se llama exactamente igual a este, solo que va a tener la extensión punto
text.
Punto test js y van a ver que el iconito cambia como un tubo de ensayo ahí bien bonito.
Entonces, el objetivo de esta parte de mi testing es que yo pueda probar algo.
Yo voy a probar si esta función la llamo dos veces, que el segundo balanceados hace nada más.
Entonces podemos escribir de scripts.
Voy a colocar pruebas en sync.
Voy a poner aquí Sync Divi.
Luego tenemos esa función.
Espero que esto no sea complicado de seguir para las personas que no son familiares con JavaScript.
Pero no se preocupen mucho.
Y aquí voy a escribir.
Debe de ejecutar el proceso dos veces, por ejemplo.
Tenemos esta función.
Y aquí adentro, voy a mandar a llamar el zinc.
Debe Asegúrese de importar zinc.
Debe de s paz.
Se intimide.
C paz.
Lo mandó llamar una vez.
Y yo sé que esta función regresa un número.
Entonces puedo almacenar ese número.
Por ejemplo, Constante Times va a ser igual a Div.
Si yo hago el log de Times debería de ver en consola el número.
Voy a poner C, llamo y voy a colocar una coma con Times.
Porque básicamente lo que estoy haciendo es crearme un agrupado de mis pruebas y luego hago una prueba
que se dice que debe ejecutarse dos veces.
Todavía no se está ejecutando dos veces, pero lo que quiero es ejecutar esta prueba para ejecutar todo
mi test suit, que así se conocería como todo el conjunto de las pruebas automáticas.
Podemos subir un poco y aquí donde tenemos los scripts del test, me dice que no hay nada de las pruebas.
Entonces voy a borrar esto.
Y escribamos nada más.
Eso es todo.
Graves en los campos.
Regresemos a nuestra terminal.
Y si escribo npm, run test, me van a preguntar.
Y por qué con el esta no escribimos run?
Porque es un comando especial.
Usualmente siempre usamos el run, npm, run, test.
Presionen enter y aquí van a ver que tenemos un solo que dice tick.
Cada múltiplo de cinco se imprimió.
Se llamó uno y es mi propio testing.
Esto es lo de la función y esto es lo del propio test y eso está bien y me dice que la prueba pasó,
etc y todo pasó bien porque nosotros no hicimos ningún ninguna.
No estaba esperando nada de esta prueba.
Recuerden, si ustedes quieren saber más sobre testing, tengo muchos cursos al respecto de esto, especialmente
los que dicen de ser experto.
Usualmente todos estos vienen con parte de testing.
En fin, para no hacer muy largo el video voy a escribir aquí Expect expect paréntesis.
Yo estaría esperando por ejemplo que times el valor de Thames TV.
Por favor escríbanlo exactamente igual con la V mayúscula por ejemplo, que sea dos punto y coma.
Entonces yo estoy esperando que Times sea dos, pero no tiene sentido porque la primera vez y la única
vez que lo estoy ejecutando, entonces debería ser uno.
Y luego estoy diciéndole que espere que dos sea igual a uno, sea igual a dos.
Esto no tiene sentido y no va a pasar la prueba.
Si yo intento ejecutar nuevamente el npm run test, van a notar que va a fallar y me dice prueba.
En fin, de V falló.
Debe ejecutar el proceso dos veces y aquí tenemos que estaba esperando un dos.
Se recibió un uno y el error está aquí.
Entonces esta prueba falla al fallar una prueba.
Esto lanza un error por decirlo así.
Y cuando yo mandé a llamar este proceso del testing en alguna parte de mi Docker Field, al lanzar este
error del testing porque una prueba no pasa, no se va a generar la imagen, lo cual es algo que nosotros
ocupamos hacer.
Nuevamente ocupamos hacer esta parte del testing.
Entonces, para pasar la prueba, obviamente lo que voy a hacer es voy, voy a volver a mandar, a llamar
de B una una primera vez, luego lo voy a volver a llamar aquí.
Entonces la segunda vez que lo llamo aquí, thanks y debería ser dos.
Entonces voy a grabar los cambios, voy a regresar a la terminal, voy a volver a ejecutar el test Swift
y van a ver que todo pasa sin ningún problema.
Tenemos muchos console logs por aquí.
Ok?
Tenemos muchos console docs, pero digamos que esos los vamos a dejar por ahí.
Técnicamente no deberíamos dejar esos console docs, pero los voy a dejar ahí solo por bueno, tal vez
este de aquí se lo puedo quitar, pero los demás los voy a dejar porque me interesa que miremos esas
partes, me interesa que se vea que se está llamando la función propiamente y esto es una breve, brevísima
prueba automática, la cual nos va a servir a nosotros para determinar si algo falla, que no construya
la imagen y si todo lo hace bien, construye la imagen.
Y este este paso es sumamente importante.
Por ahora dejémoslo así cerremos, cerremos todo, cerremos, cerremos el app, cerremos el Docker field
y en la próxima clase vamos a incorporar el proceso de pruebas automáticas en la construcción de nuestra
imagen.
Y si la prueba falla, que no construye nada.
Pero si todo sale bien, entonces que continuemos y esto va a ser muy educativo.
En la parte que falte, no tanto para la parte no, porque recuerden no es un curso de Node, no es
un curso de testing, pero esos son conocimientos básicos que ustedes van a ocupar para construir cualquier
tipo de aplicación.
Ustedes pueden hacer testing en Java en Cesar, pueden hacerlo en cualquier otra tecnología.
Dejémoslo.
Está ese punto y lo veo en la próxima clase.