Olá a todos, aqui é a equipe ! Possivelmente, muitos de vocês nos conhecem através . Para aqueles que acabaram de se conectar: estamos desenvolvendo um IDE para trabalhar com a API TestMace. A pergunta mais frequente ao comparar o TestMace com produtos concorrentes é: "O que vocês oferecem que é diferente do Postman?". Decidimos que era hora de dar uma resposta abrangente a essa pergunta. Abaixo, listamos nossas vantagens em relação ao .
Divisão em nós
Se você trabalha com o Postman, sabe que a interface da solicitação contém todas as funcionalidades necessárias. Temos scripts, testes e, na verdade, as próprias solicitações. Isso facilita o trabalho para iniciantes, mas em grandes cenários, essa abordagem não é flexível. E se você quiser criar várias solicitações e realizar uma agregação delas? E se você quiser executar um script sem uma solicitação ou vários scripts logicamente separados em sequência? Afinal, não seria bom separar testes de scripts utilitários comuns? Além disso, a abordagem de "adicionar toda a funcionalidade em um nó" não é escalável — a interface se torna rapidamente sobrecarregada.
O TestMace, desde o início, divide toda a funcionalidade em diferentes tipos de nós. Quer fazer uma solicitação? Aqui está um nó. Quer escrever um script? Aqui está um nó. Precisando de testes? Por favor — nó. Ah, e você ainda pode encapsular tudo isso em um nó. E tudo isso se combina facilmente. Essa abordagem é não apenas muito flexível, mas também, de acordo com o princípio da responsabilidade única, permite usar apenas o que você realmente precisa no momento. Por que eu precisaria de scripts e testes se quero apenas fazer uma solicitação?
Formato legível por humanos do projeto
Entre o TestMace e o Postman, há uma diferença conceitual na forma como os dados são armazenados. No Postman, todas as solicitações são armazenadas em algum lugar no armazenamento local. Se for preciso compartilhar solicitações entre vários usuários, será necessário utilizar a sincronização embutida. Na verdade, essa é uma abordagem comum, mas com suas desvantagens. E sobre a segurança dos dados? Algumas políticas empresariais podem proibir o armazenamento de dados por terceiros. Entretanto, acreditamos que o TestMace pode oferecer algo melhor! E o nome dessa melhoria é "formato legível por humanos do projeto".
Vamos começar pelo fato de que no TestMace existe a entidade "projeto". O aplicativo foi originalmente desenvolvido com foco no armazenamento de projetos em sistemas de controle de versão: a árvore do projeto é projetada praticamente idêntica à estrutura de arquivos, utilizando o formato YAML (sem parênteses ou vírgulas desnecessárias), e a representação em arquivos de cada nó é detalhadamente descrita na documentação com comentários. Mas, na maioria dos casos, você não precisará olhar para isso — todos os nomes dos campos têm denominações lógicas.
O que isso oferece ao usuário? Isso permite uma mudança muito flexível no fluxo de trabalho da equipe, utilizando abordagens familiares. Por exemplo, os desenvolvedores podem armazenar o projeto no mesmo repositório que o backend. Nos branches, além de alterar diretamente a base de código, o desenvolvedor pode corrigir os cenários de solicitação existentes e testes. Após registrar as alterações no repositório (git, svn, mercurial — o que você preferir), o CI (sua ferramenta favorita, não imposta por ninguém) inicia nossa ferramenta de linha de comando , e o relatório gerado após a execução (por exemplo, no formato junit, que também é suportado no testmace-cli) é enviado para o sistema correspondente. E a questão mencionada acima sobre segurança não é mais um problema.
Como você pode ver, o TestMace não impõe seu ecossistema ou paradigma. Em vez disso, ele se integra facilmente a processos já estabelecidos.
Variáveis dinâmicas
O TestMace segue o conceito de no-code: se um problema pode ser resolvido sem o uso de código, nós tentamos dar essa oportunidade. Trabalhar com variáveis é exatamente uma funcionalidade onde, na maioria dos casos, pode-se evitar programação.
Exemplo: recebemos uma resposta do servidor, e queremos salvar parte da resposta em uma variável. No Postman, escreveríamos algo como o seguinte no script de teste (o que por si só é estranho):
var jsonData = JSON.parse(responseBody);
postman.setEnvironmentVariable("data", jsonData.data);Mas, na nossa opinião, escrever um script para um cenário tão simples e frequentemente usado parece excessivo. Portanto, no TestMace há a opção de atribuir a variável um pedaço da resposta, utilizando a interface gráfica. Veja como é simples:
E agora, a cada solicitação, essa variável dinâmica será atualizada. Mas você pode argumentar que a abordagem do Postman é mais flexível e permite não apenas fazer uma atribuição, mas também realizar algum pré-processamento. Veja como é possível modificar o exemplo anterior:
var jsonData = JSON.parse(responseBody);
postman.setEnvironmentVariable("data", CryptoJS.MD5(jsonData.data));Bem, para isso, o TestMace possui um nó que cobre esse cenário. Para reproduzir o caso anterior, mas já na execução do TestMace, é necessário criar um nó de script após a solicitação e usar o seguinte código como script:
const data = tm.currentNode.prev.response.body.data;
tm.currentNode.parent.setDynamicVar('data', crypto.MD5(data));Como você pode ver, a composição dos nós também foi muito útil aqui. E para um caso tão simples como o descrito acima, você pode simplesmente atribuir a expressão ${crypto.MD5($response.data)} a uma variável criada através da interface gráfica!
Criação de testes através da GUI
O Postman permite criar testes por meio da escrita de scripts (no caso do Postman, em JavaScript). Essa abordagem tem apenas benefícios — flexibilidade praticamente ilimitada, soluções prontas, etc.
No entanto, muitas vezes a realidade é que o testador não possui habilidades de programação, e gostaríamos que a equipe já pudesse trazer benefícios. Para esses casos, seguindo o conceito no-code, o TestMace permite criar testes simples através da interface gráfica, sem recorrer à escrita de scripts. Veja, por exemplo, como é o processo de criação de um teste que compara valores para igualdade:
No entanto, a criação de testes no editor gráfico não exclui a possibilidade . Aqui estão todas as mesmas bibliotecas que no nó de script, e para escrever testes.
A possibilidade de executar um cenário já existente por meio de um link (nó Link)
Muitas vezes surgem situações em que uma determinada solicitação ou até mesmo um cenário inteiro precisa ser executado várias vezes em diferentes partes do projeto. Exemplos dessas solicitações incluem autenticação personalizada em várias etapas, ajuste do ambiente para o estado desejado, etc. Em geral, falando em termos de linguagens de programação, gostaríamos de ter funções que possam ser reutilizadas em diferentes partes do aplicativo. No TestMace, essa função é realizada nó. Usá-lo é muito simples:
1) crie uma solicitação ou script
2) crie um nó do tipo Link
3) nos parâmetros, indique o link para o script criado no primeiro passo
Em uma versão mais avançada, você pode especificar quais variáveis dinâmicas do script passar para o nível acima em relação ao link. Parece confuso? Digamos que criamos uma Pasta chamada . Assim, um novo nó será criado na árvore e uma aba deste nó será aberta. Definiremos os seguintes parâmetros da solicitação:, dentro da qual a variável dinâmica postIdé atribuída a este nó. Agora, no nó Link create-post-link , você pode especificar claramente que a variável postId deve ser atribuída ao ancestral. create-post-linkEste mecanismo (mais uma vez, falando na linguagem dos programadores) pode ser usado para retornar um resultado de uma ‘função’. No geral, é ótimo, DRY em pleno vigor e novamente nenhuma linha de código foi prejudicada.
Quanto ao Postman, o pedido de recurso para reutilização de solicitações , e parece até que há , de que eles estão trabalhando nessa questão. Na forma atual, o Postman tem, claro, a capacidade de mudar o fluxo de execução, o que, em teoria, pode permitir implementar esse tipo de comportamento, mas isso é mais uma solução improvisada do que uma abordagem realmente funcional.
Outras diferenças
- Maior controle sobre o escopo das variáveis. O menor escopo dentro do qual se pode definir uma variável no Postman é a coleção. O TestMace permite definir variáveis para qualquer solicitação ou pasta. No Postman, compartilhar coleção permite exportar apenas coleções, enquanto no TestMace o compartilhamento funciona para qualquer nó
- O TestMace suporta , que por padrão podem ser aplicados a solicitações filhas. Sobre isso, o Postman tem , e isso está até fechado, mas como solução é sugerido… . No TestMace, tudo isso é configurado através da interface gráfica e há a possibilidade de desativação opcional de cabeçalhos herdados em descendentes específicos.
- Desfazer/Refazer. Funciona não apenas na edição de nós, mas também ao mover, deletar, renomear e em outras operações que alteram a estrutura do projeto.
- Os arquivos anexados às solicitações se tornam parte do projeto e são armazenados junto com ele, sincronizando perfeitamente, ao contrário do Postman. (Sim, não é mais necessário escolher arquivos manualmente a cada vez que roda e enviá-los aos colegas em arquivos zip)
Recursos que já estão a caminho
Não conseguimos resistir à tentação de revelar um pouco sobre os próximos lançamentos, especialmente porque o funcionalismo é muito atraente e já está passando por polimentos finais. Então, vamos lá.
Funções
Como é conhecido, para gerar valores no Postman, usamos as chamadas variáveis dinâmicas. e a grande maioria das funções serve para gerar valores fictícios. Por exemplo, para gerar um e-mail aleatório, é necessário escrever:
{{$randomEmail}}No entanto, como se trata de variáveis (ainda que dinâmicas), não podem ser usadas como funções: elas não são parametrizáveis, portanto, não é possível obter um hash da string.
Na TestMace, planejamos adicionar funções 'justas'. Dentro de ${}, será possível não apenas acessar uma variável, mas também chamar uma função. Ou seja, se precisar gerar o famoso e-mail fictício, basta escrever
${faker.internet.email()}Além de ser uma função, pode-se notar que há a possibilidade de chamar métodos de objeto. E em vez de uma grande lista plana de variáveis dinâmicas, temos um conjunto de objetos logicamente agrupados.
E se quisermos calcular o hash de uma string? Fácil!
${crypto.MD5($dynamicVar.data)}Pode-se notar que, como parâmetros, é até possível passar variáveis! Neste ponto, o leitor curioso pode suspeitar de algo…
Uso de JavaScript nas expressões
… E não é à toa! Quando as exigências para as funções foram formuladas, de repente chegamos à conclusão de que nas expressões era necessário permitir a escrita de JavaScript válido. Portanto, agora você está livre para escrever expressões no estilo:
${1 + '' + crypto.MD5('asdf')}E tudo isso sem scripts diretamente nos campos de entrada!
Quanto ao Postman, aqui só é possível usar variáveis, e, ao tentar escrever uma expressão mais elaborada, o validador reclama e se recusa a calculá-la.
Autocompletar avançado
Atualmente, a TestMace tem autocompletar padrão, que se parece com o seguinte:
Aqui, além da string autocompletada, é indicado a que pertence essa string. Este mecanismo funciona apenas em expressões envoltas em colchetes ${}.
Como você pode notar, foram adicionados marcadores visuais que indicam o tipo de variável (por exemplo, string, número, array, etc.). Também é possível mudar os modos de autocompletar (por exemplo, você pode escolher autocompletar variáveis ou cabeçalhos). Mas isso não é o mais importante!
Em primeiro lugar, o autocompletar funciona até mesmo em expressões (onde isso é possível). Veja como fica:
E em segundo lugar, agora o autocompletar também está disponível em scripts. Dê uma olhada em como isso funciona!
Não faz sentido comparar essa funcionalidade com o Postman — lá, o autocompletar é limitado apenas a listas estáticas de variáveis, cabeçalhos e seus valores (me corrija se eu esquecer de algo). Scripts não são autocompletados 🙁
Conclusão
Em outubro, completou um ano desde o início do desenvolvimento do nosso produto. Nesse tempo, conseguimos fazer muita coisa e em alguns parâmetros alcançamos nossos concorrentes. Mas, de qualquer forma, nosso objetivo é criar uma ferramenta realmente prática para trabalhar com APIs. Temos muito trabalho pela frente, aqui está um plano aproximado de desenvolvimento do nosso projeto para o próximo ano: .
Seu feedback nos permitirá se orientar melhor na abundância de recursos, e seu apoio nos dá força e confiança de que estamos fazendo algo significativo. Acontece que hoje é um dia importante para o nosso projeto — o dia da publicação do TestMace na . Por favor, apoie nosso projeto, isso é muito importante para nós. Especialmente porque na nossa página do PH hoje há uma oferta atraente, e ela é limitada.
Fonte: habr.com
