Desarrolladores: Trucos semanales

Aprende con TDD (pruebas unitarias)

Prueba ahora LinkedIn Learning sin cargo y sin compromiso.

Prueba gratis Mostrar modalidades de suscripción
Aprende los mejores trucos y tips, y descubre los conceptos básicos indispensable para todo desarrollador web, independientemente de tu experiencia. Si ya llevas desarrollando por años o si vienes del mundo del diseño y jamás has tocado una sola línea de código, todo lo que aprenderás con esta serie semanal de trucos serán una gran adición a tu actividad profesional y apuntalará tus habilidades como programador o desarrollador. Descubre desde increíbles consejos para que puedas tratar con tu cliente y saber cómo cobrar adecuadamente, hasta cuestiones técnicas claves para organizar y gestionar mejor tu tiempo y proyectos desarrollando.
09:43
  Añadir a marcadores

Transcripción

Si bien existen muchas formas de aprender, todo el mundo te dirá siempre que usar una u otra opción siempre son las mejores. Y, claro, te quedarás con la que mejor te funcione a ti. Sin embargo, existen algunas formas que te recomiendo consideres, pues podrías estar aprendiendo mucho en muy poco tiempo. Una de estas formas es el Test-driven development y consiste en realizar evaluaciones unitarias a tu código mientras programas. ¿Qué? ¡Un momento! Espera. Primero entendamos en qué consiste esto del TDD o Test-driven development. Consiste en realizar pruebas unitarias a toda la aplicación que estés haciendo para así reducir dramáticamente el nivel y cantidad de errores que se te pudieran presentar. De allí viene, que cada vez que inicias con un lenguaje nuevo, consideres este acercamiento desde el primer "¡Hola mundo!" que hagas. Así te acostumbras a que todos tus métodos y clases estén acompañados siempre de pruebas unitarias desde un inicio. Con las pruebas unitarias podrás identificar claramente las entradas y salidas de tu programa, con lo cual podrás entender claramente el flujo de una aplicación en un lenguaje nuevo. Elijamos un caso de uso, ya que aprendimos JavaScript, bajo el modelo de Test-driven development. Para trabajar bien con este esquema que es TDD o Test-driven development, debemos estar realizando pruebas a nuestro código. En este caso, lo que vamos a estar trabajando serán dos tipos de archivos. Un archivo que se encontrará dentro de una carpeta tests, pues ahí van a estar todas las pruebas que vamos a estar realizando, y un archivo que estará dentro de nuestra carpeta app que serán los archivos finales. En este caso, vamos a agregar la extensión -spec para que podamos identificar cuál es el tipo de archivo. Vamos a comenzar. Lo primero que tenemos que hacer es la instalación de Mocha y Chai, que son las dos librerías que me van a permitir a mi trabajar con ese tipo de pruebas. Una vez que las tenga instaladas, simplemente voy a poder ejecutarlas. Para instalarlas utilizaremos npm, tendremos los comandos npm install chai y npm install mocha. Ya que las tenemos listas, voy a limpiar aquí la pantalla, primero voy a identificar mis archivos de JavaScript. En este caso, tengo dos operaciones. Mi archivo es una calculadora, tengo la operación multiplicar y dividir. Puedo agregar las operaciones que quiera, lo que tengo que hacer es dejarlas expuestas, y para esto voy a ocupar el método exports y con la ayuda de Mocha y Chai me voy a traer este tipo de datos. Así que, así los dejaré expuestos para poderlos utilizar. Es todo lo que yo trabajaré de este lado. Me voy ahora al archivo calculadora-spec.js y aquí lo primero que voy a hacer será invocar a chai. Con esto, ya tengo la librería que voy a empezar a utilizar para traerme los archivos, y comenzar a hacer este tipo de pruebas. Lo siguiente es que voy a utilizar el archivo de calculadora. Tengo que invocarlo de una manera. En este caso, aquí tengo la calculadora, del cual estoy guardando la referencia en la variable con el mismo nombre, esto para evitar alguna confusión. Vamos a escribir las pruebas. Realmente escribir una prueba es como hacer un caso de uso. Es decir, ¿qué pasaría si le mando tales números? ¿O qué pasaría si hago tal operación? Lo único que tengo que hacer es decirle: "Espero que si hago una multiplicación me arroje tal tipo de resultado" Y lo que va a hacer esto es ejecutar ciertas pruebas para ver que funcione. Con esto reducimos increíblemente el rango de error. Entonces, vamos a comenzar primero con la primera expresión que será describe. Y aquí con describe, vamos a enviar como primer parámetro el nombre de lo que yo quiero describir. En este caso, voy a trabajar con una calculadora. Y después de esto vamos a agregar una función anónima. Dentro de esta función anónima, puedo agregar todos los elementos que necesite estar evaluando, porque en resumen tengo la calculadora y dentro voy a tener sus operaciones. Así que voy a tener algo similar a este mismo método. En el primer caso, no se va a llamar obviamente calculadora, tengo que cambiar el nombre. En el primer caso es lo que sucede si voy a multiplicar. Y en el segundo caso lo que sucede si voy a dividir. Así tengo ya declaradas las descripciones y simplemente puedo agregar un nivel más donde aquí voy a decir lo que sucederá. En este caso, indicamos que lo que sucederá en el caso de la multiplicación es que va a multiplicar dos números. Y de la misma manera, enviamos aquí function para que sea anónimo, y listo. En sí estas son las pruebas que estamos utilizando. Así que aquí en la calculadora, va a realizar una multiplicación, dentro de la cual tendrá que multiplicar dos números. El mismo caso sucede con la división donde tendrá que dividir dos números; en lugar de multiplicar, escribiremos dividir. Solo vamos a corregir aquí, porque escribí mal, no es if es it. Listo. Ahora sí, ya que lo tengo aquí, vamos a poner puntos y comas que aunque no son requeridos siempre es bueno escribirlos para ir delimitando nuestros niveles. Y, en esta situación, primero comencemos con la multiplicación. Lo que vamos a hacer es declarar una variable que se llama resultado. var resultado. Y lo que estaremos haciendo es una invocación. En este caso, vamos a invocar el método multiplicar. La instancia en la referencia de la calculadora la tenemos en la variable con el mismo nombre, Así que diremos calculadora. ¿Recuerdan que teníamos los exports de este lado? Esos exports me sirven para acceder directamente a la función que necesito. Entonces, será calculadora, punto, multiplicar, aquí obviamente toma mucho sentido, y esa función multiplicar que tenía declarada acá recibe dos valores. Así que enviamos dos valores. Enviamos por ejemplo 2,5. Esto es un ejemplo, y para la multiplicación que veremos ejecutar acá 2*5 es igual a 10. Así que tengo que indicar a la prueba qué tiene que esperar. "Tú tienes que esperar que el resultado sea igual a 10". En este caso, estoy describiendo un cierto caso de uso, lo que va a hacer Mocha como tal es que va a llegar este nivel y va a invocar la función multiplicar con estos parámetros para verificar que realmente recibo un 10. Si recibe un 10 entonces la prueba pasa, si no recibe un 10 hay algún error. Exactamente va a suceder lo mismo con la otra función, solo que aquí en lugar de multiplicar va a ser dividir. Y vamos a cambiar los parámetros, por ejemplo, vamos a poner 20 y vamos a poner 2, igual el resultado tendrá que ser 10. Ahora, ¿cómo vamos a ejecutar estas pruebas? Para ejecutarlas simplemente tendremos que escribir Mocha y vamos a utilizar la ubicación donde está nuestra calculadora, nuestra prueba, que eso es lo que queremos probar. Y por aquí simplemente vamos a ponerle un poco de gracia a la terminal invocando a un reportero, en este caso el nyancat. Así que ejecuto esta instrucción, y cuando se ejecuta me indica que todo pasó correctamente. Obviamente es una prueba muy corta, así que esta prueba corrió muy rápido. ¿En qué momento podría suceder algún error? Por ejemplo, vamos a calculadora, y en la función multiplicar en lugar de que esté el asterisco ¿qué tal si está el símbolo de más? Actualizo, ejecuto nuevamente mi prueba, y aquí vamos a presentar un error, porque la calculadora simplemente en su método de multiplicar cuando está multiplicando dos números recibe un error puesto que recibe 7 en lugar del 10 que estaba esperando. Como vemos esa lógica falla y me está notificando de eso. Esa es una muy buena forma de detectar un error y obviamente estamos detectando el error previo a entrar a producción. Ahora, ¿qué sucede si lo dejo y cambio, por ejemplo, el nombre de alguna variable? En lugar de que nosotros tengamos datoA, vamos a poner dataA. Y ahora sí, volvemos a correr nuevamente, y cuando lo corremos inmediatamente me dice: "Hay un error de referencias porque datoA no existe". Está tratando de leer este datoA, pero no tiene ninguna referencia de eso. Me pongo a leer y veo que aquí puse dataA en lugar de datoA, también para ese tipo de cosas me ayuda. Y como ven, aquí el mismo reportero, que es el nyancat, me arroja los resultados de cada una de las pruebas. En teoría, solamente pasé una prueba y fallé la otra. Estás son las dos pruebas que tengo aquí descritas. Si tuviera una calculadora que tuviera más operaciones, tendría más resultados que mostrar. Así, ya podemos tener pruebas muy sencillas de nuestro código. La recomendación es que, cada vez que vayas a trabajar, comiences siempre haciendo tus pruebas. ¡Oye! Es muy fastidioso y mucho trabajo. Sí, pero a la larga cuando terminas el proyecto, tendrás muchos menos bots que atender, y por tanto, podrás terminar tu proyecto en un tiempo más corto.