Pruebas pequeñas, grandes resultados

En el tutorial de hoy, vamos a hablar sobre las pruebas atómicas automatizadas. Las pruebas atómicas automatizadas son una excelente manera de actualizar tus pruebas de interfaz de usuario y hacerlas menos frágiles y mucho más rápidas. Vamos a ver algunos ejemplos de estas pruebas atómicas automatizadas e incluso las vamos a implementar en dos aplicaciones web.

Una aplicación tendrá un formulario web HTML y la otra utilizará un token web JSON para la autenticación. Mi nombre es Nikolay Advolatkin, Arquitecto de Soluciones Senior en Sauce Labs y fundador de ultimateQA.com. ¿A qué estás esperando? Vamos a ver cómo implementar las pruebas atómicas automatizadas.

Una prueba atómica automatizada es una prueba que evalúa solo una característica o componente. Por lo general, tienen muy pocas interacciones con la interfaz de usuario y solo tocan un máximo de dos pantallas, especialmente en la automatización de la interfaz de usuario del front-end. La razón por la que digo que generalmente tocan un máximo de dos pantallas es porque estas pruebas atómicas automatizadas suelen tener un estado de configuración donde necesitan establecer el estado de una aplicación y luego un estado posterior a la configuración donde necesitan realizar una validación. Las pruebas atómicas automatizadas tienen varias ventajas, ya que son mucho más rápidas y estables que las pruebas automatizadas típicas debido a que disminuyen la cantidad de latencia con la que tenemos que lidiar y disminuyen la cantidad de interacciones con la interfaz de usuario que tenemos que realizar.

Ahora tengo una pregunta para ti. Esta prueba aquí, si la observas y la analizas, ¿crees que esta prueba es atómica? A primera vista, esta prueba puede parecer atómica, ¿verdad? En el sentido de que inicia sesión, valida que hayamos podido iniciar sesión y luego agrega un artículo al carrito y verifica que se haya agregado un artículo al carrito. Está cerca de ser atómica, sin embargo, en realidad no lo es. La razón por la que no lo es es porque tiene que iniciar sesión y validar que hayamos iniciado sesión correctamente. No hay razón por la que no podamos probar el inicio de sesión de la interfaz de usuario en una prueba separada y asegurarnos de que funcione y luego, lo que esta prueba realmente se preocupa, lo que realmente quiere probar es esta parte aquí. Y así podemos ahorrar tiempo y estabilidad al realizar estas interacciones sin utilizar la interfaz de usuario.

Las pruebas atómicas pueden tener muchas formas. Algunas de ellas pueden ser extremadamente simples. Por ejemplo, cuando solíamos escribir pruebas atómicas automatizadas que hacen clic en enlaces, en realidad tenemos una acción y una validación desperdiciadas en el sentido de que necesitamos hacer clic en un enlace y verificar que el enlace vaya al lugar correcto. Lo que realmente nos interesa es el atributo Ahref del enlace, que podríamos validar fácilmente de esta manera, haciendo que nuestra prueba sea más rápida y menos frágil.

Continuemos y echemos un vistazo a nuestra primera aplicación web, que tendrá un formulario web HTML, y podremos iniciar sesión en este formulario web HTML. Pero en lugar de utilizar la interfaz de usuario, que no es eficiente ni atómica, podremos realizar una solicitud web que dejará una cookie en nuestro navegador, y luego podremos omitir el inicio de sesión sin interactuar con la interfaz de usuario. Si vamos a esta aplicación, hay muchas pruebas aquí, pero voy a centrarme en una a la vez, solo para que puedas entender mejor. La prueba más fácil de entender, que es el caso de prueba positivo, será este caso de prueba llamado Redirecciona al Panel de Control al Iniciar Sesión.

Este es el caso de prueba positivo en el que visitamos la página de inicio de sesión, y por cierto, puedes ver nuestra aplicación a la derecha, si no estás familiarizado con Cypress. Muestra la ejecución de la prueba a la izquierda, con la aplicación real a la derecha, y si quieres explorar la aplicación en otro navegador, definitivamente puedes hacerlo. Aquí está, y realiza exactamente las mismas operaciones, pero con Cypress, por ejemplo, es muy fácil, ya que puedes ver lo que hace la prueba y luego ver la aplicación real a la derecha e incluso interactuar con ella si quieres. Puedes ver que el primer paso que hace esta prueba es visitar el inicio de sesión de nuestra aplicación que está en localhost 7077, y después de eso, realiza las operaciones estándar que esperarías para poder iniciar sesión en la aplicación, ¿verdad? Entonces va a obtener el nombre de usuario y escribir Jane Lane. Va a obtener el campo de contraseña y escribir la contraseña y luego va a enviar el formulario. Una vez que se envía el formulario, puedes ver que hacemos algunas aserciones. Primero, que la página del panel de control está ahí, ¿verdad? Entonces nuestra URL incluye panel de control. Así que eso significa que pudimos iniciar sesión correctamente. Segundo, obtenemos el encabezado y verificamos que contenga Jane Lane. Por lo tanto, estamos comprobando no solo que hemos iniciado sesión, sino que contiene el usuario correcto y obtenemos la cookie que corresponde a nuestro inicio de sesión y nos aseguramos de que exista una cookie. Echa un vistazo a la pestaña de aplicaciones aquí y en nuestras cookies. Actualmente, no hay nada disponible aquí. Lo he borrado. Pero si volvemos a ejecutar la prueba, y por supuesto, como mencioné, interactúa con la aplicación realmente iniciada sesión. Puedes ver que ahora hay una cookie de sesión de Cypher que se ha creado, por eso podemos iniciar sesión a través de la aplicación. El desafío con esta prueba es que, nuevamente, no es atómica, ¿verdad? En el sentido de que interactúa con este formulario de inicio de sesión, luego inicia sesión y luego valida que hemos iniciado sesión.

Entonces eso es genial. Pero si quisieras realizar cualquier tipo de acciones más allá de esto, para el inicio de sesión, estaríamos haciendo lo mismo una y otra vez cada vez. Y así es repetitivo e innecesario, y tal vez podamos hacer que esa acción sea más atómica. Pero déjame mostrarte el resto de las pruebas, para que entiendas mejor lo que la aplicación puede hacer.

Así que descomenté la única parte de la prueba. Y ahora tenemos todas las pruebas disponibles aquí. Y estas pruebas, por supuesto, como buenas pruebas de extremo a extremo o cualquier tipo de prueba, nos ayudan a comprender la funcionalidad de la aplicación sin tener que recorrerla manualmente.

La primera prueba aquí se llama no autorizado. Y la expectativa aquí es que seas redirigido al visitar la barra diagonal panel de control. Entonces, si no has iniciado sesión, deberías ser redirigido. Y eso es lo que hace esta prueba. Intenta visitar el panel de control, pero luego se redirige a que no has iniciado sesión y no puedes acceder a esta página. Por lo tanto, hay una aserción que obtiene el H3 y verifica ese mensaje. Y verifica que la URL incluya 'no autorizado', ¿verdad? Entonces, si no has iniciado sesión, no puedes acceder a la página del panel de control. Si intentamos iniciar sesión haciendo una solicitud GET en la página del panel de control, tampoco podremos hacerlo. Y esperamos recibir una respuesta 302 como resultado cuando intentamos iniciar sesión sin una cookie. Y también esperamos que la respuesta contenga 'no autorizado' en el cuerpo.

Si intentas interactuar con el formulario real e iniciar sesión en él con, por ejemplo, un usuario inválido y una contraseña válida, esperamos que se muestre un error y que el error indique que el nombre de usuario y/o la contraseña son incorrectos. Y en caso de éxito, ya has visto esto. Si visitamos el panel de control, ingresamos el usuario válido y la contraseña válida, obtenemos un éxito en el sentido de que puedes visitar el panel de control por sí solo. Esta prueba es atómica y excelente, y es muy útil para probar una sola vez. Una vez que puedes iniciar sesión con el formulario web a través de la interfaz de usuario, sabes que va a funcionar y ya no es necesario repetirlo en el resto de las pruebas.

Entonces, ¿cómo lo hacemos atómico? En este caso, para esta aplicación web con un formulario web HTML, la forma en que funciona es enviando una solicitud. ¿Cómo se vería realmente un inicio de sesión atómico por debajo? Bueno, como puedes ver en la documentación de esta prueba aquí, simplemente podemos realizar una solicitud web que nos permitirá iniciar sesión. La solicitud web simplemente será un POST a la URL de inicio de sesión, pasando el nombre de usuario y la contraseña válidos. Y luego eso automáticamente establecerá la cookie de sesión y a partir de ese punto, podemos realizar cualquier operación que queramos que esté detrás de la interfaz de la aplicación privada. Así que déjame mostrarte cómo se ve exactamente eso. Y aquí puedes ver que se realiza el POST al inicio de sesión, ¿verdad? Y luego te muestro que la cookie existe. Y de hecho, incluso podemos simplemente hacer, echar un vistazo a esta prueba para que esté enfocada. Volver aquí a la aplicación, deshacernos de esto y luego si lo volvemos a ejecutar, vamos a poder ver que hay una cookie.

Y no sucedió nada en nuestra aplicación, ¿verdad? Pero si, por ejemplo, ahora intentamos acceder al panel de control porque hemos iniciado sesión y tenemos una cookie en nuestro navegador, podemos acceder sin tener que iniciar sesión. Esta vez, en lugar de que nuestra aplicación sea un formulario web HTML, en realidad va a utilizar tokens web JSON. Los tokens web JSON son un método estándar de la industria muy común para autenticarse en aplicaciones y permitir el acceso a ciertas partes de la aplicación basado en este token web. Si quieres obtener más información al respecto, puedes ir a este sitio web, JWT.IO, pero básicamente, la forma en que funciona es que envías una solicitud con tu nombre de usuario y clave de acceso o nombre de usuario y contraseña, y luego, en función de eso, la aplicación verificará si existen en la base de datos. Obtendrás un token que se ve así y ahora este token es lo que puedes usar para la autenticación, algo muy común en muchas aplicaciones en la actualidad. Por lo tanto, es extremadamente útil poder hacer esto en nuestras pruebas automatizadas. Aquí está el repositorio en el que vamos a trabajar. Como antes, es muy similar. Esta carpeta en la que estoy es parte de una carpeta mucho más grande. Puedo mostrarte exactamente aquí. Puedes ver que la carpeta en la que estoy es 'logging-in JWT'. Si navego hacia arriba, puedes ver que estoy en el repositorio de ejemplos más grande de Cypress. Y como dije, estamos trabajando en la carpeta de inicio de sesión de tokens web JSON. La aplicación en la que vamos a trabajar es una aplicación Vue, y puedes ver las instrucciones sobre cómo iniciar la aplicación aquí, lo cual hice aquí. En realidad, simplemente ejecuté 'npm run start' para iniciar la aplicación. Y así está funcionando aquí. Luego, en otra ventana de terminal, ejecuté 'npm run Cypress open', y eso abrió mi navegador Cypress. Ahora, echemos un vistazo a las pruebas para ver exactamente qué están haciendo y cómo hacerlo a través de la interfaz de usuario, y luego cómo hacerlo sin una interfaz de usuario de manera atómica.

La forma en que esta aplicación va a funcionar es que enviará las credenciales de inicio de sesión y luego esas credenciales de inicio de sesión se almacenarán en el almacenamiento local en un elemento llamado usuario. Puedes ver en esta captura de pantalla aquí, ahí está nuestro token. Y luego cualquier solicitud que hagamos después que esté detrás de esta información de autorización, requerirá la cabecera de autorización con un token de portador para poder acceder a los recursos. Y así, si por ejemplo, echamos un vistazo a la pestaña de red aquí bajo los usuarios, verás que hay una autorización y un token de portador con el JSON Web Token, y eso es cómo los usuarios pueden acceder a diferentes partes de la aplicación.

Una vez que Cypress esté en funcionamiento, podremos ver estos dos casos de prueba aquí, ¿verdad? Uno utiliza la interfaz de usuario y el otro no. Si abrimos este caso de prueba que utiliza la interfaz de usuario, verás todas las pruebas que se realizan, ¿de acuerdo? Utilizando la interfaz de usuario, será algo muy estándar. Ya has visto antes, que básicamente consiste en obtener el nombre de usuario, escribir ese nombre de usuario, escribir la contraseña en el campo de contraseña y luego hacer clic en el botón de inicio de sesión y puedes ver lo que sucede antes y después. Después, básicamente estamos verificando aquí. Puedes ver que hay una solicitud web de un estado 200 y luego realizamos varias operaciones, como asegurarnos de que estamos en la URL correcta, esperar que se muestre este encabezado e incluso esperar que haya un elemento con un nombre de usuario, un nombre y un apellido, y que tenga este token que es un JSON Web Token y esperamos que sea una cadena. Y luego hay muchas más afirmaciones en diferentes partes de la solicitud web. Incluso hay más afirmaciones como esta que verifica que haya un enlace de cierre de sesión y luego hace clic en el enlace de cierre de sesión y verifica que estemos en la página de inicio de sesión. Entonces, si intentas acceder a localhost:4000/usuarios, esta URL, obtendrás un error de no autorizado, ¿verdad? Obtendrás este mensaje de error. Si intentamos acceder a esta aplicación con un token no válido, porque no podemos llegar allí. Y así, se supone que debemos recibir un 401. ¿De acuerdo? Entonces, si venimos aquí e inspeccionamos y vamos a la pestaña de red, y luego hacemos una solicitud XHR a usuarios, obtendremos aquí un 401. Puedes ver que el documento de usuarios devuelto fue 401 porque no estás autorizado. Y esto obviamente muestra un caso de prueba positivo y un caso de prueba negativo a través de la interfaz de usuario. Oh, y aquí hay uno con la interfaz de usuario que intentará iniciar sesión con un nombre de usuario no válido. ¿De acuerdo? Escribiendo un nombre de usuario, escribiendo una contraseña incorrecta y luego haciendo clic para iniciar sesión. Y luego, por supuesto, obtendrá que el nombre de usuario o la contraseña son incorrectos. Y por eso se realiza esa afirmación para asegurarse de que exista. Así que esa es nuestra prueba de interfaz de usuario. Maravilloso. Nuevamente, en localhost será mucho más complicado cuando lo implementemos en un entorno en el que tengamos que viajar a través de la red para interactuar con esto y también será más frágil como resultado. Por lo tanto, podemos evitar todo esto utilizando solicitudes web como lo hicimos con la aplicación web anterior. Entonces, si queremos hacer que la misma prueba sea atómica, tenemos estos casos de prueba aquí y los voy a ejecutar. Desafortunadamente, no son tan útiles para ver a través de la interfaz de usuario de Cypress porque realizan varias solicitudes web. Por lo tanto, la información detrás de ellos no es muy útil, pero puedes ver cómo podemos hacer una solicitud autenticada, asegurarnos de que estamos conectados y mostrar un usuario cargado. En cambio, podemos ver el código para comprender cómo hacer esto posible con JWT. Entonces, si observamos este archivo spec.cy.js, podemos ver que el primer paso que hacemos es golpear un punto final para autenticar a un usuario con un nombre de usuario y una contraseña, y luego almacenar el cuerpo devuelto dentro del usuario. Luego, para poder agregar el elemento a nuestro almacenamiento local, necesitamos establecer ese elemento llamado usuario y convertir ese usuario en una cadena, lo que permite ese Bare Token. Y así, una vez que se establece, podemos intentar golpear este punto final con este Bare Token y podemos acceder a este usuario, sin el cual, en este momento, no podríamos acceder a él. Pero con él, podemos. Y luego, por supuesto, como resultado, podemos verificar diferentes tipos de condiciones, para ser o no ser visibles. Y eso es todo. Hemos creado una prueba atómica automatizada utilizando un mecanismo de inicio de sesión JSON Web Token. Ahora, en realidad, hay muchos tipos diferentes de mecanismos de inicio de sesión y algunos pueden ser relevantes para tu aplicación, otros no. Hay muchos más ejemplos aquí, como verás en este repositorio. Verás todos estos ejemplos de inicio de sesión aquí, desde Basic Auth hasta Single Sign-on, por lo que dependiendo de tu aplicación, utilizarás el mecanismo de inicio de sesión relevante. Además, como bonificación, he vinculado muchos recursos adicionales sobre cómo hacer pruebas atómicas automatizadas en el archivo ReadMe, está al final del ReadMe, así que asegúrate de revisarlo. Muchas gracias por acompañarme en el tutorial de hoy sobre pruebas atómicas automatizadas y si quieres saber más sobre mí o ponerse al día conmigo, puedes encontrarme en ultimateQA.com o en mi canal de YouTube o en cualquiera de estas otras redes sociales que se muestran a continuación. Gracias nuevamente por tu tiempo y nos vemos la próxima vez. Cuídate.