Hola a todos, somos ! Es posible que muchos nos conozcan de . Para aquellos que recién se conectan: desarrollamos un IDE para trabajar con API TestMace. La pregunta más común al comparar TestMace con productos competidores es: "¿Qué los diferencia de Postman?". Decidimos que era hora de dar una respuesta detallada a esta pregunta. A continuación, enumeramos nuestras ventajas sobre .
División en nodos
Si trabajas con Postman, sabes que la interfaz de solicitud contiene toda la funcionalidad necesaria. Aquí están los scripts, las pruebas y, en sí, las solicitudes. Esto simplifica el trabajo para los principiantes, sin embargo, en escenarios grandes, este enfoque no es flexible. ¿Qué ocurre si deseas crear varias solicitudes y hacer agregación con ellas? ¿Qué pasa si quieres ejecutar un script sin una solicitud o varios scripts lógicamente separados en secuencia? Al final, sería bueno separar las pruebas de los scripts utilitarios normales. Además, el enfoque de "agregar toda la funcionalidad en un nodo" no es escalable: la interfaz se vuelve rápidamente abrumadora.
TestMace divide inicialmente toda la funcionalidad en diferentes tipos de nodos. ¿Quieres hacer una solicitud? Aquí tienes un nodo. ¿Quieres escribir un script? Aquí tienes un nodo. ¿Necesitas pruebas? Aquí tienes — nodo. Ah, y además puedes envolver todo esto en un nodo. Y todo esto se puede combinar fácilmente. Este enfoque no solo es muy flexible, sino que, de acuerdo con el principio de responsabilidad única, permite utilizar solo lo que realmente necesitas en este momento. ¿Para qué necesito scripts y pruebas si solo quiero hacer una solicitud?
Formato legible por humanos del proyecto
Entre TestMace y Postman hay una diferencia conceptual en la forma de almacenamiento. En Postman, todas las solicitudes se almacenan en algún lugar en el almacenamiento local. Si existe la necesidad de compartir solicitudes entre varios usuarios, se debe utilizar la sincronización integrada. De hecho, este es un enfoque común, no exento de desventajas. ¿Qué pasa con la seguridad de los datos? La política de algunas empresas puede prohibir almacenar datos con terceros. Sin embargo, creemos que TestMace puede ofrecer algo mejor. Y el nombre de esta mejora es "formato legible por humanos del proyecto".
Empecemos por el hecho de que en TestMace existe la entidad "proyecto". Y la aplicación se desarrolló originalmente con el objetivo de almacenar proyectos en sistemas de control de versiones: el árbol del proyecto se proyecta prácticamente uno a uno en la estructura de archivos, utilizando yaml como formato de almacenamiento (sin paréntesis ni comas innecesarias), y la representación de archivos de cada nodo está detalladamente descrita en la documentación con comentarios. Pero en la mayoría de los casos, no necesitará mirar allí: todos los nombres de los campos tienen nombres lógicos.
¿Qué le ofrece esto al usuario? Esto permite cambiar el flujo de trabajo del equipo de manera muy flexible, utilizando enfoques familiares. Por ejemplo, los desarrolladores pueden almacenar el proyecto en el mismo repositorio que el backend. En las ramas, además de modificar la base de código propiamente dicha, el desarrollador puede corregir los escenarios de solicitudes existentes y las pruebas. Después de confirmar los cambios en el repositorio (git, svn, mercurial — lo que prefiera), CI (su preferido, no impuesto por nadie) ejecuta nuestra utilidad de consola , y el informe obtenido tras la ejecución (por ejemplo, en formato junit, que también es compatible con testmace-cli) se envía al sistema correspondiente. Y la cuestión de la seguridad mencionada anteriormente ya no es un problema.
Como puede ver, TestMace no impone su ecosistema y paradigma. En cambio, se integra fácilmente en procesos ya establecidos.
Variables dinámicas
TestMace sigue el concepto de no-code: si es posible resolver un problema sin usar código, tratamos de ofrecer esa posibilidad. Trabajar con variables es precisamente la funcionalidad en la que, en la mayoría de los casos, se puede prescindir de la programación.
Ejemplo: recibimos una respuesta del servidor y queremos guardar parte de la respuesta en una variable. En Postman, escribiríamos algo en el script de prueba (lo cual es extraño en sí mismo) como:
var jsonData = JSON.parse(responseBody);
postman.setEnvironmentVariable("data", jsonData.data);Pero en nuestra opinión, escribir un script para un escenario tan simple y frecuentemente utilizado parece excesivo. Por eso, en TestMace hay la opción de asignar un fragmento de la respuesta a una variable, utilizando una interfaz gráfica. Observe qué tan simple es:
Y ahora, con cada solicitud, esta variable dinámica se actualizará. Pero usted podría objetar, argumentando que el enfoque de Postman es más flexible y no solo permite hacer asignaciones, sino también realizar algún pre procesamiento. Así es como se puede modificar el ejemplo anterior:
var jsonData = JSON.parse(responseBody);
postman.setEnvironmentVariable("data", CryptoJS.MD5(jsonData.data));Bueno, para esto TestMace tiene un nodo que cubre este escenario. Para reproducir el caso anterior, pero ya en la ejecución de TestMace, es necesario crear un nodo script tras la solicitud y utilizar el siguiente código como script:
const data = tm.currentNode.prev.response.body.data;
tm.currentNode.parent.setDynamicVar('data', crypto.MD5(data));Como pueden ver, la composición de nodos aquí también ha sido útil. Y para un caso tan sencillo como el que se describe arriba, incluso puede simplemente asignar la expresión ${crypto.MD5($response.data)} a una variable creada a través de la interfaz gráfica.
Creación de pruebas a través de la GUI
Postman permite crear pruebas mediante la escritura de scripts (en el caso de Postman, esto es JavaScript). Este enfoque tiene muchas ventajas: flexibilidad prácticamente ilimitada, soluciones listas, etc.
Sin embargo, la realidad es que a menudo (no somos nosotros, es la vida) el tester no tiene habilidades de programación, pero le gustaría contribuir al equipo desde ya. Para tales casos, siguiendo el concepto de no-code, TestMace permite crear pruebas simples a través de la interfaz gráfica sin necesidad de escribir scripts. Aquí hay un ejemplo de cómo se ve el proceso de creación de una prueba que compara valores por igualdad:
Sin embargo, la creación de pruebas en el editor gráfico no elimina la posibilidad de Aquí están las mismas bibliotecas que en el nodo script y para escribir pruebas.
La posibilidad de ejecutar un escenario existente a través de un enlace (nodo Link)
Frecuentemente surgen situaciones en las que es necesario ejecutar cierta solicitud, o incluso todo un escenario, varias veces en diferentes partes del proyecto. Ejemplos de tales solicitudes pueden incluir una autorización personalizada multi-etapa, llevar el entorno al estado necesario, etc. En términos de lenguajes de programación, sería deseable tener funciones que se puedan reutilizar en diferentes partes de la aplicación. En TestMace, esta función está implementada. nodo. Usarlo es muy sencillo:
1) crea una solicitud o guion
2) crea un nodo del tipo Link
3) en los parámetros, especifica el enlace al guion creado en el primer paso
En una versión más avanzada, puedes indicar qué variables dinámicas del guion pasar al nivel superior en relación con el enlace. ¿Suena confuso? Supongamos que hemos creado una Carpeta llamada crear-publicación, dentro de la cual se asigna al nodo una variable dinámica postId. Ahora, en el nodo Link create-post-link puedes especificar explícitamente que la variable postId se asigne al ancestro create-post-link. Este mecanismo (nuevamente, hablando en términos de programación) se puede utilizar para devolver un resultado de una "función". En general, genial, DRY al máximo y nuevamente, ninguna línea de código se ha dañado.
En cuanto a Postman, la solicitud de función para reutilizar solicitudes , y parece que incluso hay , de que están trabajando en este problema. En su forma actual, Postman ciertamente tiene la capacidad de cambiar el flujo de ejecución, lo que teóricamente podría permitir implementar tal comportamiento, pero es más un hack sucio que un enfoque realmente efectivo.
Otras diferencias
- Mayor control sobre el ámbito de visibilidad de las variables. El ámbito más pequeño dentro del cual se puede definir una variable en Postman es la colección. TestMace permite definir variables para cualquier solicitud o carpeta. En Postman, compartir colección solo permite exportar colecciones, mientras que en TestMace el intercambio funciona para cualquier nodo.
- TestMace soporta , que se pueden insertar por defecto en solicitudes hijas. En Postman hay , y está incluso cerrada, pero como solución se propone... . En TestMace todo esto se configura a través de la interfaz gráfica y hay posibilidad de desactivar opcionalmente los encabezados heredados en descendientes específicos.
- Deshacer/Rehacer. Funciona no solo al editar nodos, sino también al mover, eliminar, renombrar y otras operaciones que cambian la estructura del proyecto.
- Los archivos adjuntos a las solicitudes se convierten en parte del proyecto y se almacenan junto con él, además se sincronizan perfectamente, a diferencia de Postman. (Sí, ya no es necesario seleccionar manualmente archivos cada vez que inicias y pasarlos a los compañeros en archivos comprimidos).
Funciones que ya están en camino.
No pudimos resistir la tentación de desvelar un poco del misterio sobre los próximos lanzamientos, especialmente cuando las funcionalidades son muy atractivas y ya están en la fase de pulido previo al lanzamiento. Así que, ¡bienvenidos!
Funciones
Como es bien sabido, para generar valores en Postman se utilizan las llamadas variables dinámicas. y la gran mayoría de las funciones sirven para generar valores ficticios. Por ejemplo, para generar un correo electrónico aleatorio se necesita escribir:
{{$randomEmail}}Sin embargo, dado que son variables (aunque sean dinámicas), no se pueden usar como funciones: no son parametrizables, por lo tanto, no se puede obtener un hash de la cadena.
En TestMace planeamos agregar funciones "honestas". Dentro de ${} no solo se podrá referirse a una variable, sino también llamar a una función. Es decir, si necesitas generar el famoso correo electrónico falso, simplemente escribiremos
${faker.internet.email()}Además de ser una función, se puede observar que hay posibilidad de invocar un método de objeto. Y en lugar de una larga lista plana de variables dinámicas, tenemos un conjunto de objetos lógicamente agrupados.
¿Y si queremos calcular un hash de una cadena? ¡Fácil!
${crypto.MD5($dynamicVar.data)}Se puede notar que incluso se pueden pasar variables como parámetros. En este punto, el lector curioso puede sospechar que hay algo extraño...
Uso de JavaScript en expresiones
... Y no es en vano. Al formular los requisitos para las funciones, de repente llegamos a la conclusión de que se debe permitir escribir JavaScript válido en las expresiones. Por lo tanto, ahora puedes escribir expresiones al estilo de:
${1 + '' + crypto.MD5('asdf')}¡Y todo esto sin scripts directamente en los campos de entrada!
En cuanto a Postman, aquí solo se pueden usar variables y, al intentar escribir alguna expresión, el validador se queja y se niega a calcularla.
Autocompletado avanzado
Actualmente, TestMace tiene un autocompletado estándar, que se ve de la siguiente manera:
Aquí, además de la cadena autocompletada, se indica a qué pertenece dicha cadena. Este mecanismo solo funciona en expresiones rodeadas por los corchetes ${}.
Como puedes notar, se han añadido marcadores visuales que indican el tipo de variable (por ejemplo, cadena, número, array, etc.). También se pueden cambiar los modos de autocompletado (por ejemplo, se puede elegir autocompletado con variables o encabezados). Pero incluso esto no es lo más importante.
Primero, el autocompletado funciona incluso en expresiones (donde es posible). Así es como se ve:
Y en segundo lugar, ahora el autocompletado también está disponible en scripts. ¡Mira cómo funciona!
No tiene sentido comparar esta funcionalidad con Postman — allí el autocompletado se limita solo a listas estáticas de variables, encabezados y sus valores (corrígeme si he olvidado algo). Los scripts no se autocompletan 🙁
Conclusión
En octubre se cumplió un año desde el inicio del desarrollo de nuestro producto. Durante este tiempo hemos logrado muchas cosas y en ciertos parámetros hemos alcanzado a nuestros competidores. Pero de cualquier manera, nuestro objetivo es crear una herramienta realmente conveniente para trabajar con API. Nos queda mucho trabajo por hacer, aquí tienes un plan aproximado para el desarrollo de nuestro proyecto en el próximo año: .
Tu feedback nos permitirá orientarnos mejor en la abundancia de características, y tu apoyo nos da fuerzas y confianza en que estamos haciendo lo correcto. Hoy es un día importante para nuestro proyecto: el día de la publicación de TestMace en . Por favor, apoya nuestro proyecto, es muy importante para nosotros. Además, hoy tenemos una oferta tentadora en nuestra página de PH, y es limitada
Fuente: habr.com
