Cómo Probar sus Aplicaciones Web

En la industria del software, todos prueban sus aplicaciones de alguna manera. Muchos equipos de desarrolladores tienen esquemas de prueba elaborados que están bien integrados con sus canalizaciones de integración continua, pero incluso aquellos que no tienen pruebas automáticas aún tienen que idear formas de verificar que su código funcione según lo previsto.

Crear un sitio web y hacer clic en él manualmente con la ayuda de un navegador es una variedad de pruebas. Si bien no es el más sofisticado, aún cuenta. Lo mismo ocurre con la activación de cURL en la consola y el envío de una solicitud sintética al punto final de la API que acaba de crear.

Esta publicación discutirá cómo automatizar las pruebas manuales que ya hacemos antes de sumergirnos en diferentes tipos de pruebas y metodologías.

Pruebas automatizadas

Las pruebas manuales son suficientes para aplicaciones pequeñas, pero, cuando estas aplicaciones crecen, su superficie comprobable crece con ellas, causando dos problemas.

Uno, cuando las personas tienen que realizar pruebas cada vez que se termina una nueva versión de una aplicación, pueden surgir inconsistencias. Esto es especialmente cierto si hay muchas pruebas. Dos, la persona que realiza las pruebas no puede realizar otras tareas. Con las aplicaciones grandes, las pruebas pueden tardar varios días.

La forma más lógica de resolver estos dos problemas es automatizar estas tareas manuales. Existen dos tipos principales de pruebas para aplicaciones web: pruebas de interfaz de usuario y pruebas de API. Dos herramientas pueden automatizarlos.

Pruebas de interfaz de usuario

Las pruebas de interfaz de usuario se pueden realizar con una herramienta llamada Puppeteer. Puppeteer le permite automatizar una prueba manual de interfaz de usuario utilizando JavaScript. Se instala a través de NPM con el siguiente comando:

 $ npm i puppeteer

A continuación, puede escribir un script que controle una versión sin cabeza de Chrome para ejecutar las pruebas. Este script podría tener el siguiente aspecto:

(async () => { const browser = await puppeteer.launch(); const page = await browser.newPage(); await page.goto('https://google.com', {waitUntil: 'networkidle2'}); const heading = await page.$('h1'); await browser.close(); if(!heading) console.log('No heading found!');})();

En este script, estamos iniciando una instancia sin cabeza de Chrome, navegando a example.com y buscando un elemento h1. Si no existe, se registra un mensaje de error.

Pruebas de API

Las pruebas de API se pueden automatizar a través de Postman. Postman viene con una interfaz gráfica para crear solicitudes HTTP que se pueden guardar. Estas solicitudes se pueden ejecutar más tarde con solo un clic del ratón.

Para comenzar, descargue e instale la interfaz de usuario de Postman. Se necesitan los siguientes pasos para crear y guardar una solicitud:

1. Haga clic en Crear una colección a la izquierda
2. Ingrese Mi colección como el nombre de la colección
3. Haga clic en Crear
4. Haga clic en los puntos suspensivos (…) de Mi Colección a la izquierda
5. Seleccione Agregar solicitud
6. Ingrese Mi solicitud como el nombre de la solicitud
7. Haga clic en Guardar en Mi colección

La solicitud aparece en la barra lateral izquierda debajo de la colección recién creada.

Si lo selecciona, tendrá que ingresar example.com como URL y añadir una prueba. Para agregar una prueba, haga clic en Pruebas en la barra de pestañas debajo del campo de entrada de URL.

Aparecerá un área de texto en la que puede escribir su prueba en JavaScript. El siguiente es un ejemplo de prueba:

pm.test("Status code is 200", () => { pm.response.to.have.status(200);});

Si haces clic en Guardar en la esquina superior derecha de la pantalla y envías justo después, se enviará tu solicitud. El script de prueba se ejecutará para determinar si la respuesta tiene o no el estado 200.

Tipos de Pruebas

Hay tres tipos diferentes de pruebas. Comprenderlos le permite elegir el tipo de prueba adecuado para las diversas partes de su pila de software.

Pruebas unitarias

Las pruebas unitarias son el tipo de prueba más simple. Comprueban la corrección de pequeñas partes de su código. Una prueba unitaria generalmente cubre una llamada a una función o una forma de usar una clase.

Una prueba unitaria suele ser el primer “usuario” de su código. Algunas metodologías de prueba incluso requieren que escriba la prueba antes de la implementación del código de aplicación real.

Las pruebas unitarias se pueden utilizar tanto en el desarrollo del backend como en el frontend. Algunos equipos de desarrollo utilizan pruebas unitarias para comprobar la salida DOM renderizada de pequeñas partes de su código, como formularios o menús. En el backend, las pruebas unitarias se utilizan a menudo para probar el código entre el servidor HTTP y la base de datos u otras API.

Tres corredores de prueba ampliamente utilizados para pruebas unitarias son:

– Jest-Jest se usa principalmente en el desarrollo de frontend porque viene con características únicas, como pruebas de instantáneas, que ayudan con problemas como regresiones de interfaz de usuario. Un tutorial de broma se puede encontrar aquí.

‐ AVA-AVA se ve favorecida en el desarrollo de backend porque se especializa en la ejecución altamente paralela de pruebas. Puedes encontrar un tutorial de AVA aquí.

– PHPUnit-PHPUnit es un framework popular para pruebas unitarias en PHP. Un tutorial de PHPUnit se puede encontrar aquí.

Si una prueba unitaria requiere algunos recursos externos, como conexiones de red o bases de datos, es probable que esté escribiendo una prueba de integración. Este tipo de prueba se cubre a continuación.

Pruebas de integración

Desde el punto de vista de la implementación, las pruebas de integración parecen pruebas unitarias. La diferencia es que las pruebas de integración prueban varias partes de la pila juntas. Por ejemplo, pueden probar si el cliente y el servidor hablan el mismo protocolo o, en una arquitectura de microservicios, si los servicios funcionan correctamente juntos o no.

Las comprobaciones que normalmente terminarían en varias pruebas unitarias independientes se pueden agregar en una prueba de integración que determina si todo funciona bien en conjunto.

Las pruebas de integración se utilizan tanto en el desarrollo del frontend como en el backend. A veces se usan para ver si las dos partes interactúan correctamente, pero también se pueden usar para determinar si los diferentes módulos de una parte funcionan juntos según lo previsto.

Puede utilizar los mismos corredores de prueba para las pruebas de integración que utilizó para las pruebas unitarias. Sin embargo, Postman, la herramienta de interfaz de usuario utilizada anteriormente para automatizar las pruebas manuales de API, también viene con una herramienta de CLI llamada Newman que se puede integrar con su canalización de CI/CD.

Newman puede ejecutar colecciones de Postman exportadas, lo que le permite crear solicitudes y pruebas con la interfaz de usuario de Postman y ejecutarlas posteriormente a través de la interfaz de línea de comandos. Un tutorial de Newman se puede encontrar aquí.

Si una prueba de integración requiere interacción con la interfaz de usuario, se denomina siguiente con dirección de prueba de interfaz de usuario.

Pruebas de interfaz de usuario

Las pruebas de interfaz de usuario son las pruebas más sofisticadas. Intentan emular el comportamiento de los usuarios de manera automatizada para que los evaluadores no tengan que hacer clic en cada parte de su aplicación manualmente.

Las pruebas de interfaz de usuario a menudo ayudan a capturar una interacción específica que provocó un error para un usuario. Una vez capturado, se puede reproducir con un solo clic para corregir el error y evitar que regrese en una nueva versión.

Los corredores de prueba de Jest y AVA mencionados anteriormente se pueden usar aquí, pero generalmente necesitará una biblioteca adicional para facilitar la interacción de la interfaz de usuario a través de un navegador. Las dos bibliotecas principales actualmente en uso para este proceso son:

‐ Selenium-Selenium es un framework que permite el control remoto de un navegador a través de una biblioteca llamada WebDriver. Un tutorial de Selenio se puede encontrar aquí.

Hay más tipos de pruebas que las enumeradas aquí. Otros pueden tener objetivos diferentes; por ejemplo, las pruebas de carga intentan encontrar cuellos de botella de rendimiento. Tenga en cuenta que las pruebas descritas aquí a veces reciben nombres diferentes. Los tres tipos presentados anteriormente son los esenciales para implementar al comenzar. Usar uno de ellos es mejor que no usar pruebas automatizadas en absoluto.

Metodologías de prueba

Las metodologías de prueba son formas de pensar en las pruebas. Los tres que se describen a continuación son los más utilizados.

Desarrollo impulsado por pruebas (TDD)

El TDD es la metodología más utilizada y la más técnica. Recomienda que escriba sus pruebas antes de escribir el código real que desea probar. Dado que tiene que escribir una prueba solo para la parte del código que está implementando, el tipo de prueba que escribirá es una prueba unitaria.

Las pruebas unitarias son bastante granulares, por lo que, con el tiempo, el uso de esta metodología resulta en la acumulación de muchas pruebas. Esta realidad, junto con el hecho de que los practicantes de TDD principiantes tienden a escribir pruebas triviales, puede llevar a la creación de una pila de pruebas inútiles. Para evitar esto, es crucial actualizar y limpiar las pruebas cuando el equipo se haya familiarizado más con el TDD y con las pruebas en general.

Es importante ejecutar las pruebas con frecuencia, no solo en una canalización de CI / CD, sino también localmente en su máquina de desarrollo. Escriba una prueba, ejecútela, vea que falla, implemente lo suficiente para que la prueba pase y repita el proceso.

Para obtener más información, consulte la descripción de TDD de Agile Alliance.

Acceptance Test Driven Development (ATDD)

ATDD es una modificación de TDD que se centra más en casos de negocio y menos en la implementación técnica. Los tipos de prueba que se utilizan en esta metodología son en su mayoría pruebas de integración, porque, a menudo, se deben usar varias partes del sistema en conjunto para resolver una necesidad empresarial.

Dado que las pruebas son menos técnicas, también es recomendable incluir personas no orientadas técnicamente en el proceso de prueba. Los propietarios de productos y los clientes pueden ayudar a definir los casos de negocio para que un desarrollador pueda escribir una prueba para ellos. Si la prueba no se puede ejecutar con éxito, está claro que se debe implementar más funcionalidad.

ATDD funciona en un nivel de abstracción diferente al de TDD, por lo que las dos metodologías se pueden usar juntas.

Para obtener más información, consulte la descripción de TDD de Agile Alliance.

Desarrollo impulsado por el comportamiento (BDD)

El BDD es una mezcla de TDD y ATDD, y su objetivo es utilizar lo mejor de ambos mundos para hacer que el sistema en general sea más estable. BDD intenta especificar un sistema con pruebas que ilustran su uso.

Al igual que ATDD, BDD intenta capturar casos de negocio. Sin embargo, también requiere que cuestione estos casos de uso con los “5 porqués” porque los “porqués” son una parte faltante en ATDD. Por supuesto, es mejor preguntar a los clientes qué quieren en lugar de confiar únicamente en las aportaciones de los desarrolladores. Pero, también es importante cuestionar las suposiciones de ambos grupos.

BDD es también una mezcla de TDD y TDD en el sentido de niveles de abstracción. TDD solo prueba las partes pequeñas de su aplicación y ATDD solo prueba cómo funcionan juntas estas partes. BDD requiere que aplique esta metodología a la totalidad de su aplicación y sus partes pequeñas, lo que hace que BDD sea un enfoque más holístico para las pruebas.

Para obtener más información, consulte la descripción de BDD de Agile Alliance.

Conclusión

Si bien ninguna prueba es terrible, la prueba manual es mejor y la prueba automatizada es la mejor.

Dependiendo del tamaño de su aplicación, una prueba manual puede impedir que los miembros del equipo de desarrollo trabajen en otros proyectos durante días o incluso semanas, lo que le costará tiempo y dinero a su empresa. Además, la tarea monótona de realizar las mismas interacciones una y otra vez puede conducir a resbalones que a menudo se manifiestan en errores no capturados.

Las computadoras son muy buenas para repetir la misma tarea una y otra vez, por lo que es una buena idea delegar las pruebas a un script y liberar el tiempo de sus desarrolladores. Si estas pruebas están integradas en su canalización de CI/CD, las pruebas ya escritas pueden ejecutarse implícitamente cuando una nueva confirmación llegue a sus repositorios.

Es una buena idea emplear una metodología de prueba desde el principio, porque, con frecuencia, los grandes problemas al comenzar son “qué” y “cuándo” probar. Estas metodologías pueden ayudar a aclarar un proceso que hace que las pruebas de escritura sean más consistentes para todos los miembros del equipo.