¿Por qué probar mi aplicación?

Al principio, la idea de escribir código que probará el código que acabas de escribir puede parecer extraña, por lo que muchos programadores tienden a dejar de lado las pruebas. Sin embargo, al crear pruebas automatizadas para la aplicación, es mucho más fácil asegurarse de que está funcionando según lo planeado, ya que ahora con un solo comando en la terminal será posible probar todo el programa.

Dentro del mercado laboral, saber de testing es un gran diferencial y es fundamental para el desarrollo de código. Cuando tenemos pruebas en nuestro producto, podemos identificar errores durante y después del desarrollo, garantizar la funcionalidad del usuario y asegurar la calidad del software. Es decir, si todos prueban tus creaciones, nadie más necesita hacerlo.

Entendemos que todos, desde los desarrolladores hasta los evaluadores, son responsables de probar la aplicación. Entonces, ¿cómo empezamos a probar? En los próximos temas, comprenderemos las pruebas unitarias, las pruebas de integración y las pruebas de extremo a extremo.

Pruebas unitarias

Son pruebas para piezas específicas de código, como una función o un componente. Las pruebas unitarias son importantes ya que son más precisas. Cuando ocurre un error, sabemos exactamente en qué función ocurrió. Además, es la prueba que asegura que ninguna función tiene errores. Aún así, aunque las pruebas unitarias son las pruebas más importantes, no prueban las conexiones entre los componentes y no prueban la actividad del usuario, algo que veremos a continuación.

Pruebas de integración

En las pruebas de integración usamos pruebas unitarias para probar la conexión entre dos o más componentes. Es una prueba importante para asegurarse de que la comunicación entre las funciones funciona correctamente.

Pruebas de extremo a extremo

Cuando hablamos de pruebas de extremo a extremo, en el desarrollo estamos hablando de simular las actividades de los usuarios para garantizar que la aplicación funcione desde su punto de vista. Es una prueba muy importante, pero debido a que prueba la funcionalidad de todo el software, muchos terminan usando solo este enfoque. Esto da como resultado un producto poco confiable y también dificulta el mantenimiento del código.

Ahora que hemos repasados los conceptos de prueba iniciales, estamos casi listos para comenzar a probar el código. Pero ¿qué tipo de prueba para empezar?

¿Cuál prueba debo elegir?

Una empresa que construye una computadora primero prueba las partes individuales, luego la comunicación entre las partes y finalmente enciende la computadora y prueba la actividad del usuario. En consecuencia, comenzamos a probar nuestros componentes más pequeños mediante pruebas unitarias, luego pruebas de integración y luego pruebas de extremo a extremo.

Las pruebas unitarias deben cubrir la mayor parte de la aplicación, siendo en un buen código de prueba alrededor del 60-70% de su contenido, mientras que la integración alrededor del 15-20% y el resto en pruebas de extremo a extremo.
De esta forma, finalmente entendemos cuáles deben ser las prioridades y cómo dividir y organizar las pruebas dentro de los conceptos explicados anteriormente.

Veremos ejemplos que muestran cómo comenzar a usar el entorno Jest y luego cómo usar la biblioteca de pruebas de React.

Cómo empezar a usar el framework Jest

Antes de pasar a la biblioteca de pruebas de React, usaremos Jest en un entorno más simple, usando solo JavaScript Vanilla. Si quieres hacerlo como el ejemplo, sigue el paso a paso a continuación:

1) Generar un directorio para el proyecto.

mkdir my_first_jest_project
cd my_first_jest_project

2) Crear el paquete.json para instalar las dependencias.

npm init -y

3) Instalar Jest.

npm i –save-dev jest

4) Finalmente, alterar el contenido del archivo package.json.

Dentro de la propiedad “scripts” alteramos la propiedad “test”:

/package.json

Ya tenemos la configuración de prueba inicial. Después de seguir los pasos anteriores, crearemos el archivo de prueba.

Primer archivo de prueba RTL

La forma más segura de desarrollar una aplicación es con TDD (Test Driven Development), una idea que consiste en crear primero las pruebas y luego la función o componente.

Por ejemplo, crearemos una función que busque el número de identificación entre los empleados de una empresa, esta información se encuentra en un Array. Cada empleado tendrá su información separada en un Object.

Antes de crear la función, crearemos la prueba para ella:

/firstTest.test.js

Primero importamos la expectativa de la biblioteca Jest, una función que probará efectivamente nuestros retornos.

Después de eso, creamos “describe”, una función que recibe una cadena como primer parámetro y, como segundo parámetro, una función anónima donde colocaremos nuestras funciones de prueba.

La función de “test”, por otro lado, tiene una estructura idéntica para describir y es responsable de aislar los alcances. Dentro de la función test colocamos la expect, una función que comparará el retorno de la función “findEmployeeById” con la constante “employeeResult”.

Ahora que hemos probado la función, podemos comenzar a desarrollar la funcionalidad.

Nuestra función recibe el “id” y usa HOF find para buscar el objeto que tiene la propiedad id igual al id enviado como parámetro.

Como exportamos la función con el módulo, podemos importar la función al entorno de prueba:

Ahora para verificar el funcionamiento de la prueba ejecutamos el comando:

npm test

Todas las pruebas deberían pasar.

Otro dato importante es saber que existen varios comparadores distintos a toStrictEqual, como “toBe” o “toBeTruthy”. Se recomienda estudiar la propia documentación de Jest. Otros ejemplos de esto serían:

En este punto entendemos el funcionamiento básico de las pruebas y pasaremos a un nuevo ejemplo en React, en los siguientes temas entenderemos mejor cómo probar su aplicación en la práctica.

Cómo utilizar la biblioteca de pruebas de React

React Testing Library es una biblioteca liviana que tiene excelentes utilidades de prueba. Es un entorno en el que podemos probar las funciones y la interacción del usuario con la página. Así que comencemos con nuestro ejemplo.

Usando create-react-app ya tendremos todas las configuraciones iniciales para empezar a probar la aplicación.

npx create-react-app first-time-with-rtl

cd first-time-with-rtl

Ahora que tenemos nuestra configuración de RTL, crearemos una aplicación simple que puede buscar a un empleado específico o buscar a todos los empleados. Normalmente, al crear una aplicación, comenzaríamos con pruebas. Sin embargo, para que se entienda, comenzaremos con cómo funciona.

Para comenzar, crea el directorio utils dentro de /src:

/src/utils/getEmployees.js

Este rol será responsable de obtener la información de los empleados. La función es asíncrona por razones de simulación, ya que este acto normalmente lo realiza un fetch.

A continuación, crearemos el archivo que tendrá las funciones de buscar datos y cambiar el estado global.

/src/utils/helpers.js

Y finalmente, antes de probar, cambiamos el archivo App.js.

/src/App.js

Ahora que tenemos nuestros archivos de aplicación, comencemos con las pruebas unitarias, es decir, los archivos "getEmployees.js" y "helpers.js" que serán probados inicialmente.

Crea el directorio /tests en /src y dentro de él el archivo con el siguiente formato: nomeDoTeste.test.js.

/src/tests/unitaryTests.test.js

Como podemos ver en el ejemplo anterior, primero probamos la función buscando con una identificación existente, luego con una identificación inexistente y luego probamos la función findAll. Ejecute el siguiente código en la terminal para probar:

npm test

Todo debería funcionar normalmente.

Después de las pruebas unitarias, podemos comenzar con las pruebas de interacción del usuario.

Simulando al usuario con RTL

Crea un nuevo archivo de pruebas en el directorio /src/tests

/src/test/end-to-end.test.js

Inicialmente, en nuestro nuevo archivo importamos algunas funciones que usamos en las pruebas:

RTL render

Usamos la función de renderizado para renderizar un componente React específico, no necesariamente tiene que ser App.js.

RTL screen

En nuestro ejemplo, usamos la función de pantalla para ver e interactuar con un determinado elemento de la página, en nuestro caso, los botones y la entrada. Más concretamente, comenzamos seleccionando nuestros elementos con las siguientes funciones:

¿Cómo funciona screen.getByRole?

Se encarga de encontrar cierto elemento en la pantalla, si no encuentra la prueba completa da error.

¿Cómo funciona screen.queryByRole?

La consulta es muy similar a get. Sin embargo, devuelve null si no se encuentra el elemento, es decir, la prueba no da un error de bloqueo. Para seleccionar elementos de página de manera más eficiente, descarga la extensión de Chrome: Testing Playground.

¿Cómo funciona screen.findByRole?

findByRole espera un poco más para encontrar el elemento, por lo que necesitas await para asegurar que la Promise sea esperada.

Dicho esto, hemos logrado desglosar nuestras pruebas de un extremo a otro y podemos comenzar a aplicar estos conceptos a otras aplicaciones. Recomiendo estudiar más el concepto de Mocks en la documentación de RTL. Sin embargo, esto ya será suficiente para aumentar la seguridad en el desarrollo de tu código.

Conclusión

Desde el momento en que aplicamos las pruebas en cualquier proyecto, transmitimos seguridad y confiabilidad a la estructura del código. Además de ser fundamental para la creación de cualquier producto, al tratarse de un código, es mucho más fácil identificar dónde está ocurriendo el fallo y cuál es la causa probable.

Aprender pruebas es algo que todos los desarrolladores deberían practicar y muchos no lo hacen porque creen que el código no necesita usar pruebas en sus proyectos se destacará profesionalmente y facilitará la vida del desarrollador durante el mantenimiento y la aplicación de features.