Olá a todos. Estamos lentamente saindo da sombra e continuamos nossa série de artigos sobre nosso produto. Após o artigo de revisão anterior, recebemos muitos comentários (principalmente positivos), sugestões e relatórios de bugs. Hoje mostraremos o TestMace em ação e você poderá avaliar algumas funcionalidades do nosso aplicativo. Para uma imersão mais completa, recomendamos consultar nossa documentação disponível em . Então, vamos lá! http://docs-ru.testmace.comComeçaremos com o óbvio. O aplicativo está disponível e realmente pode ser testado em três plataformas — Linux, Windows, MacOS. Você pode baixar o instalador para o sistema operacional de seu interesse em

Instalação

nosso site . Para os usuários de Linux, existe a opção de instalaçãodo pacote snap . Esperamos que em breve consigamos também disponibilizá-lo na Microsoft Store e App Store (isso é necessário? O que você acha?).Cenário de Teste

Escolhemos o seguinte cenário padrão como teste:

faremos login: usuário — admin, senha — password

• vamos adicionar um novo registro
• vamos verificar a adição correta do registro
• Faremos os testes em

. Este é um simples https://testmace-quick-start.herokuapp.com/json-server , ideal para testar aplicativos desse tipo. Apenas adicionamos a autenticação por token em todas as rotas do json-server e implementamos o método login para obter esse token. Avançaremos passo a passo, aprimorando nosso projeto gradualmente.Criação de Projeto e Tentativa de Criar uma Entidade sem Autorização

Primeiro, vamos criar um novo projeto (

ArquivoNovo projeto->). Se você está executando o aplicativo pela primeira vez, um novo projeto será aberto automaticamente. Primeiro, tentaremos fazer uma solicitação para criar um novo registro (quem sabe a criação de registros esteja disponível sem autorização). Selecione no menu de contexto do nó do Projeto as opçõesAdicionar nó RequestStep -> . Como nome do nó, vamos definircriar-post . Assim, um novo nó será criado na árvore e uma aba deste nó será aberta. Definiremos os seguintes parâmetros da solicitação:Tipo de solicitação: POST

• url:
• Corpo da solicitação: json com o valor https://testmace-quick-start.herokuapp.com/posts
• {"title": "Novo post rápido do testmace"} Se você fez tudo corretamente, a interface parecerá da seguinte maneira:
  No entanto, se tentarmos realizar a solicitação, o servidor retornará o código 401, e sem autorização não teremos acesso a nada neste servidor. Bem, isso era de se esperar).

Adicionando uma Solicitação de Autorização

Como já mencionado, temos um endpoint POST

, que aceita como corpo da solicitação um json do tipo: /login, que aceita como corpo da solicitação um json do tipo: {"username": "", "password": ""}, onde nome de usuário e senha (novamente, conforme mencionado anteriormente) têm valores admin e senha respectivamente. Em resposta, este endpoint retorna um JSON do tipo {"token": ""}. Vamos utilizá-lo para autenticação. Vamos criar . Como nome do nó, vamos definir um nó chamado login, tendo como pai o nó Project. Com o uso de arrastar e soltar, mova este nó para uma posição acima do nó . Assim, um novo nó será criado na árvore e uma aba deste nó será aberta. Definiremos os seguintes parâmetros da solicitação:. Vamos atribuir os seguintes parâmetros à requisição recém-criada:

• url:
• Corpo da solicitação: json com o valor https://testmace-quick-start.herokuapp.com/login
• {"title": "Novo post rápido do testmace"} {"username": "admin", "password": "password"}

Executaremos a requisição e receberemos um código 200 com o token na resposta. Assim:

Refatoração: removendo a duplicação do domínio

Os pedidos ainda não estão relacionados em um único cenário. Mas esta não é a única desvantagem. Se observarmos de perto, podemos notar que pelo menos o domínio está duplicado em ambas as requisições. Não é ideal. É hora de refatorar esta parte do futuro cenário e isso será feito com a ajuda de variáveis.

De uma forma geral, as variáveis desempenham o mesmo papel que em outras ferramentas e linguagens de programação semelhantes - eliminar duplicação, aumentar a legibilidade, etc. Mais detalhes sobre variáveis podem ser encontrados na nossa documentação. Neste caso, precisaremos de variáveis de usuário.

Vamos definir no nível do nó Project uma variável domínio com o valor https://testmace-quick-start.herokuapp.com. Para isso, é necessário

• Abrir a aba com este nó e clicar no ícone da calculadora no canto superior direito
• Clique em + ADICIONAR VARIÁVEL
• Insira o nome e o valor da variável
  Neste caso, o diálogo com a variável adicionada será assim:

OK. Agora, graças à herança, podemos usar esta variável em descendentes de qualquer nível de profundidade. No nosso caso, são os nós login e . Assim, um novo nó será criado na árvore e uma aba deste nó será aberta. Definiremos os seguintes parâmetros da solicitação:. Para usar a variável no campo de texto, é necessário escrever ${}. Por exemplo, a URL para login se transforma em ${domínio}/login, portanto, para . Assim, um novo nó será criado na árvore e uma aba deste nó será aberta. Definiremos os seguintes parâmetros da solicitação: o nó, a URL será ${domínio}/posts.

Assim, seguindo o princípio DRY, melhoramos um pouco o cenário.

Salvamos o token em uma variável

Uma vez que estamos falando sobre variáveis, vamos desenvolver um pouco mais esse tema. No momento, quando logamos com sucesso, recebemos do servidor um token de autorização, que precisaremos em solicitações futuras. Vamos salvar esse token em uma variável. Como o valor da variável será determinado durante a execução do script, utilizaremos um mecanismo especial — variáveis dinâmicas.

Para começar, faremos uma solicitação de login. Na aba Parsed , mova o cursor sobre o token e no menu de contexto (que é aberto com o botão direito do mouse ou pressionando o botão …) selecione a opção Atribuir à variável. Uma janela aparecerá com os seguintes campos:

• Caminho — qual parte da resposta será utilizada (no nosso caso, é body.token)
• Valor atual — qual valor está no caminho Caminho (neste caso, é o valor do token)
• Nome da variável — o nome da variável onde Valor atual será armazenado. No nosso caso, será token
• Nó — em qual dos ancestrais a variável será criada Nome da variável. Vamos escolher Projeto

A janela preenchida aparece da seguinte forma:

Agora, a cada execução do nó login a variável dinâmica token será atualizada com um novo valor da resposta. E essa variável será armazenada no nó Project. nó e, graças à herança, estará disponível para os filhos.

Para acessar variáveis dinâmicas, é necessário usar a variável incorporada $dynamicVar. Por exemplo, para acessar o token salvo, é preciso chamar ${$dynamicVar.token}.

Transmitindo o token de autorização nas solicitações

Nos passos anteriores, obtivemos um token de autorização e tudo que precisamos fazer é adicionar o cabeçalho Authorization com o valor Bearer em todas as solicitações que exigem autorização, inclusive em . Assim, um novo nó será criado na árvore e uma aba deste nó será aberta. Definiremos os seguintes parâmetros da solicitação:. Existem várias maneiras para isso:

1. Copiar manualmente o token e adicionar o cabeçalho de autorização nas solicitações relevantes. Esse método funciona, no entanto sua aplicação se limita apenas a solicitações do tipo "fiz e joguei fora". Não é adequado para a execução repetida de scripts.
2. Utilizar a funcionalidade de autorização.
3. Usar cabeçalhos padrão

A utilização do segundo método parece óbvia, no entanto, no contexto deste artigo, essa abordagem... não é interessante. Afinal de contas: o mecanismo de autorizações é mais ou menos familiar para você de outras ferramentas (embora tenhamos coisas como herança de autorizações) e é pouco provável que isso desperte questões.

Outra coisa são os cabeçalhos padrão! Em poucas palavras, os cabeçalhos padrão são aqueles herdados dos ancestrais HTTP, que são adicionados automaticamente à solicitação, a menos que sejam explicitamente desativados. Com essa funcionalidade, podemos, por exemplo, implementar uma autorização personalizada ou simplesmente eliminar a duplicação em cenários. Vamos aplicar esse recurso para passar o token nos cabeçalhos.

Anteriormente, armazenamos cautelosamente o token em uma variável dinâmica $dynamicVar.token no nível do nó do Projeto. Agora, resta fazer o seguinte:

1. Definir o cabeçalho padrão Authorization com o valor Bearer ${$dynamicVar.token} no nível do nó do Projeto. Para isso, na interface do nó do Projeto, é necessário abrir o diálogo com os cabeçalhos padrão (botão Headers no canto superior direito) e adicionar o cabeçalho correspondente. O diálogo com os valores preenchidos ficará assim:
   
2. Desativar este cabeçalho na solicitação de login. Isso é compreensível: no momento do login, ainda não temos o token e, com essa solicitação, vamos exatamente estabelecê-lo. Portanto, na interface da solicitação de login, na aba Headers na área Inherited desmarcaremos a opção do cabeçalho Authorization.

Isso é tudo. Agora o cabeçalho de autorização será adicionado a todas as solicitações que são descendentes do nó do Projeto, exceto do nó de login. Assim, nesta etapa, já temos um cenário pronto e só nos resta executá-lo. Podemos executar o cenário escolhendo a opção Run no menu de contexto do nó do Projeto.

Verificamos a correção da criação da postagem

Neste estágio, nosso cenário consegue fazer login e, usando o token de autorização, criar uma postagem. No entanto, precisamos garantir que a nova postagem tenha o nome correto. Ou seja, em essência, precisamos fazer o seguinte:

• Enviar uma solicitação para obter a postagem pelo id,
• Verificar se o nome recebido do servidor corresponde ao nome enviado durante a criação da postagem

Vamos considerar o primeiro passo. Como o valor do id é determinado durante a execução do script, é necessário criar uma variável dinâmica (vamos chamá-la de postId) a partir do nó . Assim, um novo nó será criado na árvore e uma aba deste nó será aberta. Definiremos os seguintes parâmetros da solicitação: no nível do nó do Projeto. Como fazer isso já sabemos, basta consultar a seção Salvamos o token em uma variável. Resta apenas criar uma solicitação para obter a postagem por este id. Para isso, criaremos um RequestStep get-post com os seguintes parâmetros:

• Tipo de solicitação: GET
• URL: ${domain}/posts/${$dynamicVar.postId}

Para implementar o segundo passo, precisamos nos familiarizar com Assertiva nó. O nó Assertiva — é um nó que permite escrever verificações para determinadas solicitações. Cada nó Assertiva pode conter várias afirmações (verificações). Você pode ler mais sobre todos os tipos de assertivas em nosso documentação. Vamos usar Comparar assertiva com o operador igual. Existem várias maneiras de criar assertivas:

1. Longa. Manualmente, crie um nó Assertiva a partir do menu de contexto do nó RequestStep. No nó Assertiva criado, adicione a assertiva de interesse e preencha os campos.
2. Rápida. Crie um nó Assertiva junto com a assertiva da resposta do nó RequestStep usando o menu de contexto

Usaremos o segundo método. Veja como isso ficará para nosso caso.

Para quem não entendeu, aqui acontece o seguinte:

1. Fazer uma solicitação no nó get-post
2. Na aba Parsed resposta, chame o menu de contexto e selecione Criar assertiva -> Comparar -> Igual

Parabéns, criamos nosso primeiro teste! Fácil, não é? Agora você pode executar o script completo e desfrutar do resultado. Resta apenas um pouco para refatorar e mover o título para uma variável separada. Mas deixaremos isso para você como tarefa de casa :)

Conclusão

Neste guia, criamos um script completo e também fizemos uma visão geral de algumas funcionalidades do nosso produto. Claro, não utilizamos todas as funcionalidades e em próximos artigos faremos uma revisão detalhada das capacidades do TestMace. Fique de olho nas atualizações!

P.S. Para quem está com preguiça de reproduzir todos os passos, gravamos gentilmente repositório o projeto do artigo. Você pode abri-lo usando Novo projeto -> Abrir projeto e selecionar a pasta Projeto.

Fonte: habr.com