Hola a todos. Poco a poco estamos saliendo de las sombras y continuamos con nuestra serie de artículos sobre nuestro producto. Después de el artículo de presentación, recibimos numerosos comentarios (en su mayoría positivos), sugerencias e informes de errores. Hoy mostraremos en acción y ustedes podrán apreciar algunas características de nuestra aplicación. Para una inmersión más completa, recomiendo consultar nuestra documentación en . ¡Vamos allá!
Instalación
Comencemos con lo básico. La aplicación está disponible y realmente se puede probar en tres plataformas: Linux, Windows, MacOS. Puedes descargar el instalador para el sistema operativo que te interese desde . Para los usuarios de Linux, hay una opción de instalación . Esperamos que pronto tengamos una versión en Microsoft Store y App Store (¿es necesario? ¿Qué opinas?).
Escenario de prueba
Elegimos el siguiente escenario estándar como prueba:
- inicia sesión: usuario — admin, contraseña — password
- agregaremos un nuevo registro
- verificaremos la correcta adición del registro
Realizaremos las pruebas en . Este es un , perfecto para probar este tipo de aplicaciones. Solo hemos agregado autorización por token a todas las rutas del json-server y hemos creado el método de inicio de sesión para obtener dicho token. Avanzaremos de manera metódica, mejorando nuestro proyecto gradualmente.
Creación del proyecto e intento de crear una entidad sin autorización
Primero crearemos un nuevo proyecto (Archivo->Nuevo proyecto). Si estás ejecutando la aplicación por primera vez, el nuevo proyecto se abrirá automáticamente. Para comenzar, intentemos hacer una solicitud para crear un nuevo registro (quizás la creación de registros esté disponible sin autorización). Selecciona en el menú contextual del nodo Project las opciones Agregar nodo -> RequestStep. Como nombre del nodo, estableceremos crear-publicación. Esto resultará en un nuevo nodo creado en el árbol y se abrirá la pestaña de este nodo. Estableceremos los siguientes parámetros de solicitud:
- Tipo de solicitud: POST
- url:
- Cuerpo de la solicitud: json con el valor
{"title": "Nueva publicación de inicio rápido testmace"}
Si lo has hecho todo correctamente, la interfaz debería verse de la siguiente manera:
Sin embargo, si intentamos realizar la solicitud, el servidor devolverá el código 401 y sin autorización no tendremos acceso a nada en este servidor. Bueno, es algo predecible).
Agregamos la solicitud de autorización
Como se mencionó anteriormente, tenemos un endpoint POST /login, que acepta como cuerpo de solicitud un json de este tipo: {"username": "", "password": ""}, donde username y password (de nuevo, de la introducción anterior) tienen valores admin y password correspondientemente. En respuesta, este endpoint devuelve un json del tipo {"token": ""}. Lo utilizaremos para la autorización. Crearemos RequestStep un nodo llamado login, con como predecesor Proyecto el nodo. Con la función de arrastrar y soltar, mueve este nodo en el árbol por encima del nodo crear-publicación. Asignaremos los siguientes parámetros a la nueva solicitud:
- Tipo de solicitud: POST
- url:
- Cuerpo de la solicitud: json con el valor
{"username": "admin", "password": "password"}
Ejecutamos la solicitud y recibimos un código doscientos con el token en la respuesta. Algo así:
Refactorización: eliminamos la duplicación del dominio
Por ahora, las solicitudes no están conectadas en un único escenario. Pero este no es el único inconveniente. Si lo miramos de cerca, podemos notar que al menos el dominio se repite en ambas solicitudes. No es lo ideal. Es hora de refactorizar esta parte del futuro escenario y para ello nos ayudarán las variables.
En un primer acercamiento, las variables cumplen el mismo papel que en otras herramientas y lenguajes de programación similares: eliminar la duplicación, aumentar la legibilidad, etc. Para más información sobre las variables, puedes leer en . En este caso necesitaremos variables de usuario.
Definimos a nivel de Proyecto la variable del nodo dominio con el valor https://testmace-quick-start.herokuapp.com. Para esto es necesario
- Abrir la pestaña con este nodo y hacer clic en el ícono de calculadora en la parte superior derecha
- Hacer clic en + AÑADIR VARIABLE
- Ingresar el nombre y el valor de la variable
En nuestro caso, el diálogo con la variable añadida se verá de la siguiente manera:
OK. Ahora gracias a la herencia podemos usar esta variable en descendientes de cualquier nivel de profundidad. En nuestro caso, estos son los nodos login y crear-publicación. Para usar la variable en el campo de texto, es necesario escribir ${}. Por ejemplo, la url para iniciar sesión se transforma en ${domain}/login, y para crear-publicación el nodo, la url se verá como ${domain}/posts.
Así, siguiendo el principio DRY, hemos mejorado un poco el escenario.
Guardamos el token en una variable
Ya que hemos tocado el tema de las variables, ampliemos un poco este concepto. En este momento, en caso de un inicio de sesión exitoso, recibimos del servidor un token de autorización que necesitaremos en las solicitudes posteriores. Guardemos este token en una variable. Dado que el valor de la variable se definirá durante la ejecución del escenario, utilizamos para ello un mecanismo especial — .
Para empezar, realizaremos una solicitud de inicio de sesión. En la pestaña Analizado para la respuesta, coloque el cursor sobre el token y en el menú contextual (que se activa con el botón derecho del ratón o presionando el botón ...) seleccione la opción Asignar a variable. Aparecerá un cuadro de diálogo con los siguientes campos:
- Path — qué fragmento de la respuesta se toma (en nuestro caso es
body.token) - Valor actual — qué valor se encuentra en la ruta Path (en nuestro caso es el valor del token)
- Nombre de la variable — el nombre de la variable en la que Valor actual se guardará. En nuestro caso será
token - Nodo — en cuál de los ancestros se creará la variable Nombre de la variable. Seleccionaremos Proyecto
El cuadro de diálogo completado se ve de la siguiente manera:
Ahora, cada vez que se ejecute el nodo login la variable dinámica token se actualizará con el nuevo valor de la respuesta. Y esta variable se almacenará en Proyecto el nodo y, gracias a la herencia, estará disponible para los descendientes.
Para acceder a las variables dinámicas, es necesario usar $dynamicVar. Por ejemplo, para acceder al token guardado, se debe llamar a ${$dynamicVar.token}.
Transmitimos el token de autorización en las solicitudes
En los pasos anteriores, obtuvimos el token de autorización y todo lo que tenemos que hacer es agregar el encabezado Authorization. con el valor Bearer en todas las solicitudes que requieran autorización, incluidas las que crear-publicación. Para esto hay varias formas:
- Copiar manualmente el token y agregar el encabezado de autorización a las solicitudes de interés. Este método funciona, sin embargo, su aplicación se limita solo a solicitudes del tipo 'hice y descarté'. No es adecuado para ejecutar escenarios múltiples.
- Utilizar la funcionalidad de .
- Usar
El uso del segundo método parece obvio, sin embargo, en el contexto de este artículo, este enfoque... no es interesante. Bueno, en realidad: el mecanismo de autorizaciones es más o menos familiar para usted de otras herramientas (aunque tengamos cosas como ) y probablemente no planteará preguntas.
¡Lo que importa son los encabezados por defecto! En pocas palabras, los encabezados por defecto son encabezados HTTP heredados de los ancestros que se agregan automáticamente a la solicitud, a menos que se desactiven explícitamente. Con esta funcionalidad, se puede, por ejemplo, implementar una autorización personalizada o simplemente evitar la duplicación en los escenarios. Aplicaremos esta funcionalidad para transmitir el token en los encabezados.
Anteriormente, guardamos con anticipación el token en una variable dinámica $dynamicVar.token a nivel del nodo del Proyecto. Lo que queda por hacer es lo siguiente:
- Definir el encabezado predeterminado
Authorization.con el valorBearer ${$dynamicVar.token}a nivel del nodo del Proyecto. Para esto, en la interfaz del nodo del Proyecto, es necesario abrir el diálogo con los encabezados predeterminados (botón Headers en la esquina superior derecha) y agregar el encabezado correspondiente. El diálogo con los valores completados se verá de la siguiente manera:
- Desactivar este encabezado de la solicitud de inicio de sesión. Es comprensible: en el momento del inicio de sesión aún no tenemos el token y con esta solicitud de hecho lo estableceremos. Por lo tanto, en la interfaz de la solicitud de inicio de sesión en la pestaña Headers en el área Inherited desmarcaremos la opción del encabezado de Autorización.
Eso es todo. Ahora el encabezado de autorización se añadirá a todas las solicitudes que sean descendientes del nodo del Proyecto, excepto del nodo de inicio de sesión. Así que, en esta etapa, ya tenemos el escenario listo y solo queda ejecutarlo. Para ejecutar el escenario, se puede elegir la opción Ejecutar en el menú contextual del nodo del Proyecto.
Verificamos la correcta creación de la publicación
En esta etapa, nuestro escenario puede iniciar sesión y, utilizando el token de autorización, crear una publicación. Sin embargo, necesitamos asegurarnos de que la nueva publicación tenga el nombre correcto. Es decir, en esencia, queda hacer lo siguiente:
- Enviar una solicitud para obtener la publicación por id,
- Verificar que el nombre recibido del servidor coincide con el nombre proporcionado al crear la publicación
Veamos el primer paso. Dado que el valor de id se determina durante la ejecución del script, es necesario crear una variable dinámica (llamémosla postId) del nodo crear-publicación a nivel del nodo del Proyecto. Cómo hacerlo ya lo sabemos, solo es necesario acceder a la sección Guardamos el token en una variable. Solo queda crear una solicitud para obtener la publicación por este id. Para esto, crearemos un RequestStep get-post con los siguientes parámetros:
- Tipo de solicitud: GET
- URL: ${domain}/posts/${$dynamicVar.postId}
Para realizar el segundo paso, necesitamos familiarizarnos con el nodo. El nodo Assertion es un nodo que permite escribir verificaciones sobre ciertas solicitudes. Cada nodo Assertion puede contener múltiples afirmaciones (verificaciones). Puede leer más sobre todos los tipos de assertions en nuestra . Vamos a utilizar Compare assertion con el operador equal. Hay varias formas de crear assertions:
- Lento. Crear manualmente un nodo de Afirmación desde el menú contextual del nodo RequestStep. En el nodo de Afirmación creado, agregar la afirmación deseada y completar los campos.
- Rápido. Crear un nodo de Afirmación junto con la afirmación de la respuesta del nodo RequestStep usando el menú contextual.
Utilizaremos el segundo método. Así es como se verá para nuestro caso.
Para aquellos que no entendieron, aquí está lo que sucede:
- Hacer una solicitud en el nodo get-post
- En la pestaña Analizado en la respuesta, invocar el menú contextual y seleccionar Crear afirmación -> Compare -> Igual
¡Felicidades, hemos creado nuestra primera prueba! Sencillo, ¿verdad? Ahora puedes ejecutar el guion completo y disfrutar del resultado. Solo queda refactorizar un poco y extraerlo title a una variable separada. Pero dejaremos eso como tarea para ustedes)
Conclusión
En esta guía, hemos creado un guion completo y además hemos revisado algunas características de nuestro producto. Por supuesto, no hemos utilizado todas las funcionalidades, y en los próximos artículos haremos un análisis detallado de las capacidades de TestMace. ¡Mantente atento a las actualizaciones!
P.S. Para aquellos que prefieren no reproducir todos los pasos, amablemente hemos grabado con el proyecto del artículo. Se puede abrir usando Archivo -> Abrir proyecto y seleccionar la carpeta Proyecto.
Fuente: habr.com
