{"id":54188,"date":"2019-12-20T00:00:00","date_gmt":"2019-12-19T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/chem-testmace-luchshe-postman"},"modified":"2020-02-18T14:02:10","modified_gmt":"2020-02-18T11:02:10","slug":"chem-testmace-luchshe-postman","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/news\/chem-testmace-luchshe-postman","title":{"rendered":"\u00bfPor qu\u00e9 TestMace es mejor que Postman?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"\u00bfPor<\/p>\n

<\/p>\n

Hola a todos, somos TestMace<\/a><\/noindex>! Es posible que muchos nos conozcan de nuestros<\/a><\/noindex> las noticias anteriores<\/a><\/noindex> art\u00edculos<\/a><\/noindex>. Para quienes reci\u00e9n se conectan: estamos desarrollando un IDE para trabajar con la API de TestMace. La pregunta m\u00e1s com\u00fan al comparar TestMace con productos competidores es \u201c\u00bfEn qu\u00e9 te diferencias de Postman?\u201d. Hemos decidido que es hora de dar una respuesta detallada a esta pregunta. A continuaci\u00f3n, enumeramos nuestras ventajas sobre Postman<\/a><\/noindex>.<\/p>\n

<\/a><\/noindex><\/p>\n

Divisi\u00f3n en nodos<\/h2>\n

<\/p>\n

Si trabajas con Postman, sabes que la interfaz de solicitudes contiene toda la funcionalidad necesaria. Aqu\u00ed hay scripts, pruebas y, por supuesto, las propias solicitudes. Esto simplifica el trabajo para los principiantes, sin embargo, en escenarios grandes, este enfoque no es flexible. \u00bfQu\u00e9 pasa si quieres crear varias solicitudes y hacer una agregaci\u00f3n sobre ellas? \u00bfQu\u00e9 pasa si quieres ejecutar un script sin solicitud o varios scripts l\u00f3gicamente separados uno tras otro? Al final, ser\u00eda bueno separar las pruebas de los scripts utilitarios comunes. Adem\u00e1s, el enfoque de \u201cagregar toda la funcionalidad en un solo nodo\u201d no es escalable: la interfaz se carga r\u00e1pidamente.<\/p>\n

<\/p>\n

TestMace divide inicialmente toda la funcionalidad en diferentes tipos de nodos. \u00bfQuieres hacer una solicitud? Aqu\u00ed tienes un step de solicitud<\/a><\/noindex> nodo. \u00bfQuieres escribir un script? Aqu\u00ed tienes un script<\/a><\/noindex> nodo. \u00bfNecesitas pruebas? Aqu\u00ed tienes \u2014 Assertion<\/a><\/noindex> nodo. Ah, y adem\u00e1s puedes envolver todo esto en un folder<\/a><\/noindex> nodo. Y todo esto se puede combinar f\u00e1cilmente. Este enfoque no solo es muy flexible, sino que, de acuerdo con el principio de responsabilidad \u00fanica, permite utilizar solo lo que realmente necesitas en este momento. \u00bfPara qu\u00e9 necesito scripts y pruebas si solo quiero hacer una solicitud?<\/p>\n

<\/p>\n

Formato legible por humanos del proyecto<\/h2>\n

<\/p>\n

Entre TestMace y Postman hay una diferencia conceptual en la forma de almacenamiento. En Postman, todas las solicitudes se almacenan en alg\u00fan lugar del almacenamiento local. Si es necesario compartir solicitudes entre varios usuarios, se debe utilizar la sincronizaci\u00f3n integrada. De hecho, este es un enfoque com\u00fan, no exento de desventajas. \u00bfQu\u00e9 hay sobre la seguridad de los datos? Porque la pol\u00edtica de algunas empresas puede no permitir almacenar datos en terceros. Sin embargo, creemos que TestMace puede ofrecer algo mejor. Y el nombre de esta mejora es \u201cformato de proyecto legible por humanos\u201d.<\/p>\n

<\/p>\n

Empecemos por el hecho de que en TestMace existe la entidad \"proyecto\". Y la aplicaci\u00f3n se desarroll\u00f3 originalmente con el objetivo de almacenar proyectos en sistemas de control de versiones: el \u00e1rbol del proyecto se proyecta pr\u00e1cticamente uno a uno en la estructura de archivos, utilizando yaml como formato de almacenamiento (sin par\u00e9ntesis ni comas innecesarias), y la representaci\u00f3n de archivos de cada nodo est\u00e1 detalladamente descrita en la documentaci\u00f3n con comentarios. Pero en la mayor\u00eda de los casos, no necesitar\u00e1 mirar all\u00ed: todos los nombres de los campos tienen nombres l\u00f3gicos. <\/p>\n

<\/p>\n

\u00bfQu\u00e9 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\u00e1s de modificar la base de c\u00f3digo propiamente dicha, el desarrollador puede corregir los escenarios de solicitudes existentes y las pruebas. Despu\u00e9s de confirmar los cambios en el repositorio (git, svn, mercurial \u2014 lo que prefiera), CI (su preferido, no impuesto por nadie) ejecuta nuestra utilidad de consola testmace-cli<\/a><\/noindex>, y el informe obtenido tras la ejecuci\u00f3n (por ejemplo, en formato junit, que tambi\u00e9n es compatible con testmace-cli) se env\u00eda al sistema correspondiente. Y la cuesti\u00f3n de la seguridad mencionada anteriormente ya no es un problema.<\/p>\n

<\/p>\n

Como puede ver, TestMace no impone su ecosistema y paradigma. En cambio, se integra f\u00e1cilmente en procesos ya establecidos.<\/p>\n

<\/p>\n

Variables din\u00e1micas<\/h2>\n

<\/p>\n

TestMace sigue el concepto de no-code: si es posible resolver un problema sin usar c\u00f3digo, tratamos de ofrecer esa posibilidad. Trabajar con variables es precisamente la funcionalidad en la que, en la mayor\u00eda de los casos, se puede prescindir de la programaci\u00f3n.<\/p>\n

<\/p>\n

Ejemplo: recibimos una respuesta del servidor y queremos guardar parte de la respuesta en una variable. En Postman, escribir\u00edamos algo en el script de prueba (lo cual es extra\u00f1o en s\u00ed mismo) como:<\/p>\n

<\/p>\n

var jsonData = JSON.parse(responseBody);\npostman.setEnvironmentVariable(\"data\", jsonData.data);<\/code><\/pre>\n
<\/p>\n
Pero en nuestra opini\u00f3n, escribir un script para un escenario tan simple y frecuentemente utilizado parece excesivo. Por eso, en TestMace hay la opci\u00f3n de asignar un fragmento de la respuesta a una variable, utilizando una interfaz gr\u00e1fica. Observe qu\u00e9 tan simple es:<\/p>\n
<\/p>\n
\"\u00bfPor<\/p>\n
<\/p>\n
Y ahora, con cada solicitud, esta variable din\u00e1mica se actualizar\u00e1. Pero usted podr\u00eda objetar, argumentando que el enfoque de Postman es m\u00e1s flexible y no solo permite hacer asignaciones, sino tambi\u00e9n realizar alg\u00fan pre procesamiento. As\u00ed es como se puede modificar el ejemplo anterior:<\/p>\n
<\/p>\n
var jsonData = JSON.parse(responseBody);\npostman.setEnvironmentVariable(\"data\", CryptoJS.MD5(jsonData.data));<\/code><\/pre>\n
<\/p>\n
Bueno, para esto TestMace tiene script<\/a><\/noindex> un nodo que cubre este escenario. Para reproducir el caso anterior, pero ya en la ejecuci\u00f3n de TestMace, es necesario crear un nodo script tras la solicitud y utilizar el siguiente c\u00f3digo como script:<\/p>\n
<\/p>\n
const data = tm.currentNode.prev.response.body.data;\ntm.currentNode.parent.setDynamicVar('data', crypto.MD5(data));<\/code><\/pre>\n
<\/p>\n
Como pueden ver, la composici\u00f3n de nodos aqu\u00ed tambi\u00e9n ha sido \u00fatil. Y para un caso tan sencillo como el que se describe arriba, incluso puede simplemente asignar la expresi\u00f3n ${crypto.MD5($response.data)}<\/code> a una variable creada a trav\u00e9s de la interfaz gr\u00e1fica.<\/p>\n
<\/p>\n
Creaci\u00f3n de pruebas a trav\u00e9s de la GUI<\/h2>\n
<\/p>\n
Postman permite crear pruebas mediante la escritura de scripts (en el caso de Postman, esto es JavaScript). Este enfoque tiene muchas ventajas: flexibilidad pr\u00e1cticamente ilimitada, soluciones listas, etc.<\/p>\n
<\/p>\n
Sin embargo, la realidad es que a menudo (no somos nosotros, es la vida) el tester no tiene habilidades de programaci\u00f3n, pero le gustar\u00eda contribuir al equipo desde ya. Para tales casos, siguiendo el concepto de no-code, TestMace permite crear pruebas simples a trav\u00e9s de la interfaz gr\u00e1fica sin necesidad de escribir scripts. Aqu\u00ed hay un ejemplo de c\u00f3mo se ve el proceso de creaci\u00f3n de una prueba que compara valores por igualdad:<\/p>\n
<\/p>\n
\"\u00bfPor<\/p>\n
<\/p>\n
Sin embargo, la creaci\u00f3n de pruebas en el editor gr\u00e1fico no elimina la posibilidad de escribir pruebas en c\u00f3digo.<\/a><\/noindex>Aqu\u00ed est\u00e1n las mismas bibliotecas que en el nodo script y chai<\/a><\/noindex> para escribir pruebas.<\/p>\n
<\/p>\n
Otras diferencias<\/h2>\n
<\/p>\n