Por que TestMace é mellor que Postman

Por que TestMace é mellor que Postman

Ola a todos, aquí tedes TestMace! Quizais moita xente coñeza de nós dos nosos anterior artigos. Para os que acaban de unirse: estamos a desenvolver un IDE para traballar coa API de TestMace. A pregunta máis frecuente ao comparar TestMace cos produtos da competencia é "En que te diferencias de Postman?" Decidimos que era o momento de dar unha resposta detallada a esta pregunta. A continuación describimos as nosas vantaxes Carteiro.

División en nodos

Se traballas con Postman, sabes que a interface de solicitude contén todas as funcións necesarias. Hai guións, probas e, de feito, as propias solicitudes. Isto fai que sexa máis fácil para os principiantes, pero en escenarios grandes este enfoque non é flexible. E se queres crear varias consultas e realizar a agregación nelas? E se queres executar un script sen unha solicitude ou varios scripts loxicamente separados seguidos? Despois de todo, sería unha boa idea separar as probas dos scripts de utilidade habituais. Ademais, o enfoque de "engadir toda a funcionalidade nun nodo" non é escalable: a interface sobrecárgase rapidamente.

TestMace inicialmente divide todas as funcionalidades en diferentes tipos de nós. Queres facer unha solicitude? É para ti paso de solicitude nodo Queres escribir un guión? É para ti escrita nodo Necesitas probas? Por favor - Afirmación nodo Ah, si, aínda podes envolver todo isto dobrador nodo E todo isto pódese combinar facilmente entre si. Este enfoque non só é moi flexible, senón que tamén, de acordo co principio de responsabilidade única, permítelle usar só o que realmente necesita no momento. Por que necesito scripts e probas se só quero facer unha solicitude?

Formato de proxecto lexible por humanos

Hai unha diferenza conceptual entre TestMace e Postman na forma en que se almacenan. En Postman, todas as solicitudes almacénanse nalgún lugar do almacenamento local. Se hai que compartir solicitudes entre varios usuarios, entón cómpre utilizar a sincronización integrada. De feito, este é un enfoque xeralmente aceptado, pero non exento de inconvenientes. Que pasa coa seguridade dos datos? Despois de todo, a política dalgunhas empresas pode non permitir o almacenamento de datos con terceiros. Non obstante, pensamos que TestMace ten algo mellor que ofrecer. E o nome desta mellora é "formato de proxecto lexible por humanos".

Comecemos co feito de que en TestMace, en principio, hai unha entidade "proxecto". E a aplicación foi desenvolvida inicialmente co obxectivo de almacenar proxectos en sistemas de control de versións: a árbore do proxecto proxéctase case un a un na estrutura do ficheiro, úsase yaml como formato de almacenamento (sen corchetes e comas adicionais) e o a representación do ficheiro de cada nodo descríbese en detalle na documentación con comentarios. Pero na maioría dos casos non buscarás alí: todos os nomes de campo teñen nomes lóxicos.

Que lle dá isto ao usuario? Isto permítelle cambiar o fluxo de traballo do equipo de forma moi flexible, utilizando enfoques coñecidos. Por exemplo, os desenvolvedores poden almacenar un proxecto no mesmo repositorio que o backend. Nas ramas, ademais de cambiar a propia base de código, o desenvolvedor pode corrixir os scripts de consulta e as probas existentes. Despois de realizar cambios no repositorio (git, svn, mercurial - o que máis lle guste), CI (o teu favorito, non imposto por ninguén) lanza a nosa utilidade de consola testmace-cli, e o informe recibido despois da execución (por exemplo, en formato Junit, que tamén se admite en testmace-cli) envíase ao sistema apropiado. E o mencionado problema de seguridade xa non é un problema.

Como podes ver, TestMace non impón o seu ecosistema e paradigma. Pola contra, encaixa facilmente nos procesos establecidos.

Variables dinámicas

TestMace segue o concepto sen código: se un problema se pode resolver sen usar código, tentamos ofrecer esta oportunidade. Traballar con variables é exactamente a funcionalidade na que na maioría dos casos pode prescindir da programación.

Exemplo: recibimos unha resposta do servidor e queremos gardar parte da resposta nunha variable. En Postman, nun guión de proba (o que é estraño en si mesmo) escribiriamos algo así como:

var jsonData = JSON.parse(responseBody);
postman.setEnvironmentVariable("data", jsonData.data);

Pero na nosa opinión, escribir un guión para un escenario tan sinxelo e de uso frecuente parece redundante. Polo tanto, en TestMace é posible asignar un anaco da resposta a unha variable mediante a interface gráfica. Mirade que sinxelo é:

Por que TestMace é mellor que Postman

E agora con cada solicitude esta variable dinámica actualizarase. Pero pode opoñerse, argumentando que o enfoque de Postman é máis flexible e permite non só facer unha tarefa, senón tamén realizar algún procesamento previo. Aquí tes como modificar o exemplo anterior:

var jsonData = JSON.parse(responseBody);
postman.setEnvironmentVariable("data", CryptoJS.MD5(jsonData.data));

Ben, para este propósito ten TestMace escrita nodo, que abarca este escenario. Para reproducir o caso anterior, pero xa executado por TestMace, cómpre crear un nodo de script seguindo a solicitude e utilizar o seguinte código como script:

const data = tm.currentNode.prev.response.body.data;
tm.currentNode.parent.setDynamicVar('data', crypto.MD5(data));

Como podes ver, a composición dos nodos tamén serviu aquí. E para un caso tan sinxelo como o descrito anteriormente, pode simplemente asignar a expresión ${crypto.MD5($response.data)} variable creada a través da GUI!

Creación de probas mediante GUI

Postman permítelle crear probas escribindo scripts (no caso de Postman, isto é JavaScript). Este enfoque ten moitas vantaxes: flexibilidade case ilimitada, dispoñibilidade de solucións preparadas, etc.

Non obstante, a realidade adoita ser tal (non somos así, a vida é así) que un probador non ten habilidades de programación, pero gustaríalle traer beneficios ao equipo agora mesmo. Para tales casos, seguindo o concepto sen código, TestMace permítelle crear probas sinxelas a través dunha GUI sen recorrer a escribir scripts. Aquí, por exemplo, é como é o proceso de creación dunha proba que compare valores para a igualdade:

Por que TestMace é mellor que Postman

Non obstante, a creación de probas nun editor gráfico non elimina a posibilidade escribir probas en código. Aquí están todas as mesmas bibliotecas que no nodo de script, e chai para probas de redacción.

Moitas veces xorden situacións cando unha determinada consulta ou mesmo un script completo é preciso executar varias veces en diferentes partes do proxecto. Un exemplo de tales solicitudes podería ser a autorización personalizada en varias etapas, levar o ambiente ao estado desexado, etc. En xeral, falando de linguaxes de programación, gustaríanos ter funcións que se poidan reutilizar en diferentes partes da aplicación. En TestMace esta función é realizada por ligazón nodo É moi doado de usar:
1) crear unha consulta ou script
2) crear un nodo de tipo Link
3) nos parámetros, especifique unha ligazón ao script creado no primeiro paso

Nunha versión máis avanzada, pode especificar que variables dinámicas do script se pasan a un nivel superior en relación á ligazón. Soa confuso? Digamos que creamos un Cartafol co nome crear-publicación, dentro do cal se lle asigna unha variable dinámica a este nodo postId. Agora no nodo de ligazón crear-post-link pode especificar explícitamente que a variable postId asignado a un antepasado crear-post-link. Este mecanismo (de novo, en linguaxe de programación) pódese usar para devolver un resultado dunha "función". En xeral, é xenial, DRY está en pleno apoxeo e, de novo, nin unha soa liña de código foi danada.

Por que TestMace é mellor que Postman

En canto a Postman, hai unha solicitude de funcións para reutilizar solicitudes colgado dende 2015, e parece que hai incluso algunhas pistasque están a traballar neste problema. Na súa forma actual, Postman, por suposto, ten a capacidade de cambiar o fío de execución, o que en teoría probablemente fai posible implementar un comportamento similar, pero isto é máis un truco sucio que un enfoque verdadeiramente funcional.

Outras diferenzas

  • Maior control sobre o alcance das variables. O ámbito máis pequeno no que se pode definir unha variable en Postman é a recollida. TestMace permítelle definir variables para calquera consulta ou cartafol. En Postman Share a colección permítelle exportar só coleccións, mentres que en TestMace a compartición funciona para calquera nodo
  • Soporta TestMace encabezados herdables, que se pode substituír en consultas fillas por defecto. O carteiro ten algo sobre isto: a tarefa, e incluso está pechado, pero ofrécese como solución... usar scripts. En TestMace, todo isto está configurado a través da GUI e hai unha opción para desactivar opcionalmente as cabeceiras herdadas en descendentes específicos
  • Desfacer/Refacer. Funciona non só ao editar nodos, senón tamén ao mover, eliminar, renomear e outras operacións que cambian a estrutura do proxecto.
  • Os ficheiros anexos ás solicitudes pasan a formar parte do proxecto e gárdanse con el, aínda que están perfectamente sincronizados, a diferenza de Postman. (Si, xa non precisa seleccionar ficheiros manualmente cada vez que inicia e transferilos aos seus compañeiros nos arquivos)

Funcións que xa están en camiño

Non puidemos resistir a tentación de levantar o veo do segredo nos próximos lanzamentos, especialmente cando a funcionalidade é moi saborosa e xa se está a pulir antes do lanzamento. Entón, vémonos.

Funcións

Como sabes, Postman usa as chamadas variables dinámicas para xerar valores. A lista deles é impresionante e a gran maioría das funcións utilízanse para xerar valores falsos. Por exemplo, para xerar un correo electrónico aleatorio, cómpre escribir:

{{$randomEmail}}

Porén, ao tratarse de variables (aínda que dinámicas), non se poden utilizar como funcións: non son parametrizables, polo que non será posible tomar un hash dunha cadea.

Planeamos engadir funcións "honestas" a TestMace. Xusto dentro de ${} será posible non só acceder a unha variable, senón tamén chamar a unha función. Eses. se precisa xerar o notorio correo electrónico falso, simplemente escribirémoslle

${faker.internet.email()}

Ademais de que é unha función, notarás que é posible chamar a un método nun obxecto. E en lugar dunha gran lista plana de variables dinámicas, temos un conxunto de obxectos agrupados loxicamente.

E se queremos calcular o hash dunha cadea? Doadamente!

${crypto.MD5($dynamicVar.data)}

Notarás que ata podes pasar variables como parámetros! Neste punto, un lector curioso pode sospeitar que algo está mal...

Usando JavaScript en expresións

... E por unha boa razón! Cando se estaban formando os requisitos para as funcións, de súpeto chegamos á conclusión de que un javascript válido debería escribirse en expresións. Entón, agora podes escribir expresións como:

${1 + '' + crypto.MD5('asdf')}

E todo isto sen scripts, xusto nos campos de entrada!

En canto a Postman, aquí só podes usar variables, e cando intentas escribir a máis mínima expresión, o validador maldice e négase a calculala.

Por que TestMace é mellor que Postman

Autocompletado avanzado

Actualmente, TestMace ten un autocompletado estándar que se ve así:

Por que TestMace é mellor que Postman

Aquí, ademais da liña de autocompletar, indícase a que pertence esta liña. Este mecanismo só funciona en expresións rodeadas de corchetes ${}.

Como podes ver, engadíronse marcadores visuais que indican o tipo de variable (por exemplo, cadea, número, matriz, etc.). Tamén pode cambiar os modos de autocompletado (por exemplo, pode seleccionar o autocompletado con variables ou cabeceiras). Pero mesmo isto non é o máis importante!

En primeiro lugar, o autocompletado funciona mesmo en expresións (se é posible). Este é o que parece:

Por que TestMace é mellor que Postman

E en segundo lugar, o autocompletado agora está dispoñible nos scripts. Bótalle un ollo a como funciona!

Por que TestMace é mellor que Postman

Non ten sentido comparar esta funcionalidade con Postman: o autocompletado só está limitado a listas estáticas de variables, encabezados e os seus valores (corríxeme se esquecín algo). Os scripts non se completan automaticamente :)

Conclusión

Outubro cumpriu un ano dende o inicio do desenvolvemento do noso produto. Durante este tempo, conseguimos facer moitas cousas e, nalgúns aspectos, alcanzámonos aos nosos competidores. Pero sexa como for, o noso obxectivo é facer unha ferramenta verdadeiramente cómoda para traballar coas API. Aínda nos queda moito traballo por facer, aquí tedes un plan aproximado para o desenvolvemento do noso proxecto para o ano que vén: https://testmace.com/roadmap.

Os teus comentarios permitiranos navegar mellor pola abundancia de funcións e o teu apoio dános forza e confianza en que estamos a facer o correcto. Ocorre que hoxe é un día importante para o noso proxecto, o día no que se publicou TestMace Caza de produtos. Por favor apoie o noso proxecto, é moi importante para nós. Ademais, hoxe hai unha oferta tentadora na nosa páxina de PH, e é limitada

Fonte: www.habr.com

Engadir un comentario