Forem: Rafael Berçam

Mudando o Jogo com StackSpot AI & Testes Automatizados

Rafael Berçam — Wed, 30 Apr 2025 17:49:58 +0000

Introdução

Desenvolver software atualmente é uma tarefa cada vez mais desafiadora: as aplicações estão mais complexas e a pressão por entregas rápidas (e sem bugs!) só aumenta. É nesse cenário que entra a StackSpot.

A StackSpot funciona como um “hub” central onde você e seu time podem organizar, padronizar e compartilhar tudo o que precisam para criar aplicações modernas: desde componentes de código até automações e boas práticas. Ele acelera o desenvolvimento e garante qualidade do início ao fim — da primeira linha de código até o deploy em produção.

O que é hipercontextualização?

Um dos grandes diferenciais da StackSpot (especialmente da StackSpot AI) é a hipercontextualização. Mas o que isso significa na prática? Basicamente, a plataforma entende o contexto do seu projeto, do seu código e até das necessidades do seu time. Ou seja, ao usar a StackSpot AI para revisar um código, por exemplo, ele não traz apenas dicas genéricas. Ele considera o padrão do seu time, as tecnologias utilizadas e até as regras de negócio do seu projeto.

Assim, as sugestões e automações realmente fazem sentido para o seu cenário — nada de dicas fora de contexto! Isso torna o trabalho mais rápido, eficiente e com muito mais qualidade.

[Dica]
Vamos ver na prática como a StackSpot AI pode ajudar a elevar o nível do seu código? 🚀

Desafios de Qualidade de Software em Times de Alta Performance

Manter a qualidade de software em times grandes (ou mesmo em squads menores) é um grande desafio. Não basta apenas escrever código que funciona: é preciso garantir que todos sigam os mesmos padrões, que os testes automatizados cubram o que realmente importa e que o time evolua junto, sem tropeçar em bugs ou retrabalho.

Silo de Conhecimento: O Inimigo Invisível

Um dos maiores vilões é o silo de conhecimento. Sabe quando só uma ou duas pessoas do time sabem como funciona aquele teste automatizado mais complexo ou como rodar uma automação específica? Se essas pessoas saem de férias (ou mudam de empresa), o restante do time fica perdido. Isso trava a evolução e aumenta o risco de bugs passarem despercebidos.

Stack Diferente? Nem pensar!

Outro ponto: cada dev querer usar uma stack diferente pode até parecer interessante no início, mas rapidamente se torna um pesadelo. Imagine manter um projeto onde cada um usa uma linguagem, framework ou padrão de teste diferente. Fica impossível padronizar, automatizar e até mesmo dar manutenção. Por isso, alinhar a stack de desenvolvimento é fundamental para garantir qualidade e performance.

[Nota]
Essa padronização pode ser polêmica, mas a experiência reforça meu ponto de vista. Se você pensa diferente, deixe um comentário para debatermos!

Rotatividade e Falta de Capacitação

A rotatividade de profissionais e a falta de capacitação específica acabam prejudicando automações importantes. Quando o time muda muito, ou quando não há treinamentos adequados, as automações legadas ficam sem manutenção. O resultado? Testes quebrados, pipelines travados e mais bugs em produção.

[Informação]
Manter a qualidade de software é um trabalho de equipe — e depende de processos, ferramentas e, principalmente, colaboração e compartilhamento de conhecimento.

Como a StackSpot AI Pode Ajudar a Superar Esses Desafios

Diante desses obstáculos — silos de conhecimento, falta de padronização, rotatividade e automações legadas — fica claro que processos manuais não são suficientes. É aí que entra a StackSpot AI.

A plataforma foi criada para quebrar barreiras de conhecimento, padronizar práticas e automatizar tarefas repetitivas. Com recursos de IA, a StackSpot AI analisa o contexto do seu projeto, sugere melhorias de código, identifica falhas em testes automatizados e até gera documentação técnica de forma consistente.

Além disso, ao centralizar o conhecimento e as melhores práticas em um único lugar, a StackSpot AI facilita o onboarding de novos membros e reduz o impacto da rotatividade. Ou seja, mesmo que o time mude, a qualidade e a continuidade das automações permanecem garantidas.

Nos próximos tópicos, mostrarei na prática como a StackSpot AI pode transformar o dia a dia do seu time de qualidade — tornando os processos mais ágeis, seguros e colaborativos.

Como Criar uma Conta Gratuita na StackSpot AI (Trial)

Se você quer experimentar a StackSpot AI sem custo, siga os passos abaixo para criar sua conta Trial rapidamente:

Acesse o portal da StackSpot AI:

https://ai.stackspot.com/
Clique em "Sign in" para iniciar o processo de login.
Escolha uma das opções de autenticação:
- GitHub
- Microsoft
- Google

Autorize o acesso da StackSpot AI à sua conta escolhida.
Pronto! Sua conta Trial será criada automaticamente e você já pode começar a usar a StackSpot AI.

Durante o período de Trial, você terá acesso aos principais recursos da plataforma para testar e avaliar como a StackSpot AI pode ajudar seu time de qualidade.

Explorando a Home da StackSpot AI: Seu Ponto de Partida

Assim que você cria sua conta e acessa a StackSpot AI Portal, você já cai direto na página inicial da plataforma. O destaque é o chat genérico — seu assistente central, pronto para ajudar com dúvidas, sugestões de código, revisões, automações de tarefas e muito mais.

Esse chat é só o começo! O StackSpot AI oferece vários recursos avançados para tornar sua experiência ainda mais produtiva. Os principais atributos são:

Principais Atributos da StackSpot AI

1. Knowledge Source

O que é: Fontes de conhecimento que você pode adicionar ao StackSpot AI, como snippets de código, APIs, documentos técnicos, padrões internos, etc.
Para que serve: Permite que a IA gere respostas e códigos hipercontextualizados, seguindo exatamente o que seu projeto ou empresa precisa.

2. Quick Command

O que é: Comandos rápidos para automatizar tarefas comuns, como gerar código, rodar testes, fazer deploy e muito mais.
Para que serve: Economiza tempo, agiliza processos repetitivos e garante que tudo siga o padrão do time.

3. Agents

O que é: Assistentes especializados para diferentes etapas do desenvolvimento, como revisão de código, geração de user stories, identificação de vulnerabilidades, etc.
Para que serve: Trazem inteligência e automação para processos específicos, elevando a qualidade e a segurança do software.

Esses recursos podem ser acessados tanto pelo portal web quanto pelas extensões da StackSpot AI para IDEs, integrando-se facilmente ao seu fluxo de trabalho.

Criando Knowledge Sources: Hipercontextualizando sua API

Na StackSpot AI, as Knowledge Sources são a base para respostas inteligentes e alinhadas ao seu contexto. Você pode adicionar documentos técnicos, snippets, padrões internos e, claro, contratos de API no formato OpenAPI.

Por que usar OpenAPI como Knowledge Source?

Ao adicionar o documento OpenAPI da sua API como fonte de conhecimento, a StackSpot AI passa a entender todos os endpoints, parâmetros, respostas e regras do seu serviço. Assim, qualquer dúvida ou geração de código será hipercontextualizada, seguindo exatamente o contrato da sua API.

Como usar a API do Serverest como Knowledge Source na StackSpot AI

Se você quer turbinar a StackSpot AI com o contrato da API do Serverest, siga este passo a passo. Assim, a IA entenderá todos os endpoints, parâmetros e respostas da API, facilitando a geração de exemplos de código ou esclarecimento de dúvidas.

1. Baixe o arquivo Swagger da API

Acesse: swagger.json
Salve o arquivo swagger.json no seu computador.

2. Crie uma Knowledge Source na StackSpot AI

Entre no portal: https://ai.stackspot.com/
Faça login com sua conta (GitHub, Microsoft ou Google).
No menu, vá em Criar Knowledge Sources.
Selecione o tipo API.
Dê um nome, por exemplo: API Serverest.
Salve.
Clique em Add file, escolha a opção Documento e faça upload do swagger.json que você baixou.
Após o upload, a mágica acontece!

3. Pronto! Agora a IA entende a API

No chat, selecione a Knowledge Source criada para que a IA utilize o contrato da API nas respostas.

Com a KS criada, a StackSpot AI já consegue responder perguntas e gerar exemplos de código usando o contrato da API. Por exemplo:

Pergunta: Como faço para cadastrar um novo usuário na API Serverest?

Resposta

Para cadastrar um novo usuário na API ServeRest, faça uma requisição HTTP POST para o endpoint `/usuarios` com um JSON contendo os dados do usuário. Exemplo:

Endpoint:

POST /usuarios
Content-Type: application/json

Corpo da requisição:

{
  "nome": "Fulano da Silva",
  "email": "fulano@qa.com",
  "password": "teste",
  "administrador": "true"
}

Exemplo usando curl:

curl -X POST http://localhost:3000/usuarios \
  -H "Content-Type: application/json" \
  -d '{
    "nome": "Fulano da Silva",
    "email": "fulano@qa.com",
    "password": "teste",
    "administrador": "true"
  }'

Resposta esperada (201):

{
  "message": "Cadastro realizado com sucesso",
  "_id": "jogfODIlXsqxNFS2"
}

O campo `administrador` aceita "true" ou "false" (string). Não é permitido cadastrar usuário com email já utilizado.

Se precisar de exemplos em outra linguagem, me avise!

E sim, além de mostrar como cadastrar um novo usuário, a IA traz regras implícitas na documentação e exemplos de respostas do Swagger.

Já entendeu o potencial disso?

Como Criar um Agent de QA na StackSpot AI para Gerar Testes Automatizados e Cenários Gherkin

Veja o passo a passo para criar um Agent de QA que gera testes automatizados e cenários de teste em Gherkin (BDD) em português, usando a StackSpot AI:

1. Crie o Agent de QA

Acesse o Portal da StackSpot AI.
No menu lateral, clique em Contents > Agents.
Clique em Create Agents.

2. Configure o Agent

Agent name: QA Test Generator
System prompt:

Você é um especialista em qualidade de software e BDD. Gere testes automatizados (unitários ou de integração) para os endpoints da API, seguindo o contrato OpenAPI e as melhores práticas de QA. Além disso, gere cenários de teste em Gherkin (Português), utilizando a estrutura Dado, Quando, Então. Considere exemplos de payloads, cenários de sucesso e falha, e utilize frameworks populares como pytest, jest ou outros conforme a linguagem.
Suggested Prompts:
- Gere um teste automatizado para o endpoint de cadastro de usuário.
- Quais cenários negativos devo testar no endpoint de login?
- Gere cenários de teste Gherkin para o endpoint POST /usuarios.
- Crie um cenário Gherkin para o endpoint GET /produtos.
Conversational mode: Ative para permitir interações contínuas.

3. Adicione Knowledge Sources

Selecione o Swagger da sua API (já cadastrado como Knowledge Source).
Adicione também documentos internos de padrões de testes, exemplos de código ou guidelines de QA, se houver.

4. Salve e Teste o Agent

Clique em Save.
Use a seção Try para testar prompts, por exemplo: > Gere cenários de teste em Gherkin para o endpoint POST /usuarios da API Serverest, cobrindo casos de sucesso e erro.

5. Exemplo de Uso

Prompt:

Crie um cenário Gherkin para o endpoint GET /produtos.

Resposta esperada do Agent:

Funcionalidade: Listar produtos cadastrados

  Contexto:
    Dado que existem produtos cadastrados no sistema

  Cenário: Buscar todos os produtos com sucesso
    Quando o cliente realiza uma requisição GET para "/produtos"
    Então a resposta deve ter o status 200
    E o corpo da resposta deve conter uma lista de produtos
    E a propriedade "quantidade" deve indicar o número de produtos cadastrados

  Cenário: Buscar produtos com filtro de nome
    Dado que existe um produto cadastrado com nome "Logitech MX Vertical"
    Quando o cliente realiza uma requisição GET para "/produtos?nome=Logitech MX Vertical"
    Então a resposta deve ter o status 200
    E o corpo da resposta deve conter apenas os produtos com nome "Logitech MX Vertical"

  Cenário: Buscar produtos quando não há produtos cadastrados
    Dado que não existem produtos cadastrados no sistema
    Quando o cliente realiza uma requisição GET para "/produtos"
    Então a resposta deve ter o status 200
    E o corpo da resposta deve conter uma lista vazia de produtos
    E a propriedade "quantidade" deve ser igual a 0

Resumo do Agent

Ao configurar um prompt eficiente e integrá-lo a uma base de conhecimento hipercontextualizada — exclusiva da sua empresa — você transforma o Agent em um verdadeiro parceiro de trabalho. Essa abordagem potencializa a geração rápida e precisa de scripts automatizados, otimizando tarefas repetitivas e especializadas que, tradicionalmente, demandariam horas de trabalho manual. O resultado é um ganho significativo de produtividade e padronização nos processos de qualidade.

[Dica]
É possível usar uma, duas ou várias Knowledge Sources dentro de um Agent, e preparar até 4 prompts de sugestão de uso.

Quick Commands: Automatize Tarefas e Ganhe Tempo na Sua IDE

Os Quick Commands da StackSpot AI são atalhos inteligentes que ajudam a automatizar tarefas repetitivas direto na sua IDE, seja no IntelliJ ou no Visual Studio Code. Precisa gerar testes, documentar código, refatorar um trecho ou rodar um comando customizado? Com os Quick Commands, dá para fazer tudo isso rapidamente, sem sair do editor.

Como Criar um Quick Command

Acesse o Portal da StackSpot AI

No menu lateral, vá em Contents > Quick Command e clique em Create Custom Quick Command.
Escolha o tipo de comando

Selecione a opção IDE para criar comandos que rodarão direto na sua IDE.
Configure o comando

Dê um nome, slug, descrição e defina o prompt que será executado. É possível usar variáveis como {{ selected_code }} para trabalhar com o código selecionado.

Componentes do Quick Command

Prompts

Instruções em linguagem natural enviadas para a StackSpot AI. Permitem automatizar tarefas como gerar código, documentar, traduzir ou sugerir melhorias. Podem utilizar variáveis como {{ selected_code }} e inputs personalizados.

Web Requests

Permitem integrar o Quick Command com APIs externas. Você define o método HTTP, a URL (com variáveis Jinja), headers e o corpo da requisição. O resultado pode ser manipulado e apresentado ao usuário ou inserido no código.

Inputs

Perguntas feitas ao usuário antes da execução do comando. Podem ser obrigatórios ou opcionais, e seus valores podem ser usados em Prompts e Web Requests através de variáveis (ex: {{ nome_do_input }}).

Criando um Prompt para o Quick Command

Ao criar um Quick Command, um dos principais componentes é o Prompt, que permite, por meio de linguagem natural, criar instruções para serem realizadas.

No exemplo a seguir, solicitei que o código selecionado pelo usuário (uma feature escrita em Gherkin) seja convertido em steps implementados de acordo com o projeto.

[Nota]
O projeto está indexado pelo Plugin da StackSpot e funcionando como uma Knowledge Source da AI.

No prompt, utilizei o slug {create-behave-steps} e a seguinte descrição:

Ao receber a feature

Você deve gerar os steps da lib behave para implementação, seguindo os melhores padrões do mercado.
Apenas gere os steps e não precisa escrever nada anteriormente ou explicações.

O trecho {{selected_code}} corresponde ao código selecionado pelo usuário na IDE (exemplo: VS Code).

Com a flag Usar Projeto Indexado habilitada, a saída será hipercontextualizada.

Vamos testar?

Neste GIF, acionei meu QuickCommand através de uma / e selecionei para rodar o comando com a feature selecionada na IDE.

Em seguida, os steps são gerados de forma hipercontextualizada, pois estou usando minha KS (Knowledge Source) e meu projeto indexado.

Conclusão

A adoção da StackSpot AI transformou radicalmente minha rotina de trabalho. O uso combinado de Agents, Knowledge Sources e Quick Commands elevou minha produtividade a um novo patamar, permitindo enfrentar desafios de alta complexidade com muito mais agilidade e precisão.

Com os Agents, automatizo tarefas especializadas e garanto respostas contextualizadas para problemas específicos do meu domínio. As Knowledge Sources centralizam e padronizam o conhecimento do time, tornando a resolução de dúvidas e a implementação de boas práticas algo natural e acessível. Já os Quick Commands agilizam tarefas repetitivas, como geração de código e testes, liberando tempo para focar em atividades estratégicas.

O resultado é claro: processos mais rápidos, entregas com maior qualidade e uma automação sustentada por IA que realmente faz diferença no dia a dia. A StackSpot AI não só aumentou minha eficiência, mas também trouxe mais segurança e padronização para todo o ciclo de desenvolvimento. Estou colhendo frutos concretos dessa mudança — e recomendo fortemente para quem busca produtividade e inovação em times de tecnologia.

Gostou do conteúdo?

Deixe seu feedback, comentário e reação ao post. Sua participação é fundamental para que eu continue criando conteúdos.

Me siga nas redes:

🧪 Validando Mensagens no Kafka com Kotlin e Awaitility

Rafael Berçam — Tue, 04 Mar 2025 16:09:25 +0000

Fala pessoal! Neste post, vou te guiar por um exemplo prático de como testar a publicação de mensagens em um tópico Kafka usando Kotlin, Awaitility e o KafkaConsumer. Esse tipo de validação é essencial em sistemas distribuídos para garantir que as mensagens sejam enviadas e recebidas corretamente.

📚 Estrutura do Projeto

A estrutura básica do projeto é assim:

.
├── src
│   ├── main
│   │    └── kotlin
│   │         └── api
│   │              └── KafkaProducerService.kt
│   └── test
│        └── kotlin
│             └── api
│                  └── KafkaApiTest.kt
└── pom.xml (ou build.gradle.kts para Kotlin)

Certifique-se de incluir as seguintes dependências no seu pom.xml (Maven) ou build.gradle.kts (Gradle):

<dependency>
    <groupId>org.apache.kafka</groupId>
    <artifactId>kafka-clients</artifactId>
    <version>3.7.0</version>
</dependency>

<dependency>
    <groupId>org.awaitility</groupId>
    <artifactId>awaitility</artifactId>
    <version>4.2.0</version>
</dependency>

<dependency>
    <groupId>com.fasterxml.jackson.module</groupId>
    <artifactId>jackson-module-kotlin</artifactId>
    <version>2.16.0</version>
</dependency>

🤔 O Que é o Awaitility?

O Awaitility é uma biblioteca Java/Kotlin projetada para facilitar a espera por condições assíncronas em testes. Em vez de usar Thread.sleep() (o que é ineficiente), o Awaitility permite esperar de forma mais inteligente até que uma condição seja atendida.

✅ Por que usar Awaitility com Kafka?

Os consumidores Kafka não recebem mensagens imediatamente (processamento assíncrono).
Precisamos esperar até que a mensagem seja publicada no tópico e lida pelo consumidor.

📊 Exemplo Prático: Validando Transações Bancárias

Vamos criar um teste que:

Publica uma mensagem de uma transação bancária em um tópico Kafka.
Consome a mensagem do tópico.
Valida se o conteúdo recebido está correto.

🛠️ O Modelo de Transação

📬 O Teste com Kafka e Awaitility

🧐 Explicando o Teste

Produzimos uma mensagem Kafka com kafkaProducer.sendMessage().

Consumimos com kafkaConsumer.poll().
Usamos o await().untilAsserted para esperar até a mensagem ser validada.

Se a mensagem não for encontrada ou os dados estiverem incorretos, o teste falha com uma mensagem de erro clara. ✅

📢 Conclusão

Testar mensagens Kafka de forma assíncrona é essencial para garantir a integridade do sistema. Usando o Awaitility com KafkaConsumer, conseguimos validar mensagens de forma eficiente.

Se você gostou do conteúdo ou tem dúvidas, deixe um comentário! 🚀

👉 Me siga no dev.to para mais conteúdo de qualidade!

Happy coding! 💻

🔗 Links Referencias e Projeto no GitHub

Estruturação de Testes de API

Rafael Berçam — Tue, 12 Sep 2023 19:38:18 +0000

Resumo

Então, resolvi postar esse conteúdo para trazer um ponto de vista sobre a importância de estruturar seus testes de API e como isso pode tornar seu dia a dia eficiente e organizado.

Essa forma de organização é baseada em estrutura de camadas que são formas de abstrair algumas classes e responsabilidades do seu código, para torná-lo legível, de fácil manutenção e muitas boas práticas.
Como eu sei que isso pode variar de linguagem para linguagem, framework para framework, eu vou exemplificar mostrando em diferentes contextos e uso das principais linguagens do mercado.

Então bora la começar!

Introdução

Testes de API são essenciais para garantir a qualidade e confiabilidade de aplicações que utilizam APIs. Eles permitem verificar se as APIs estão funcionando conforme o esperado, identificando e corrigindo bugs antes que eles cheguem as aplicações ou sistemas clientes (consumers)

Uma boa estrutura para testes de API pode ajudar a tornar o processo de desenvolvimento e manutenção mais eficiente. Ela pode ajudar a organizar os testes, facilitar a identificação de problemas e tornar os testes mais repetíveis (reuso).

Uma boa estrutura para testes de API deve atender aos seguintes objetivos:

Organização: Os testes devem ser organizados de forma lógica e fácil de entender.
Eficiência: O processo de execução dos testes deve ser eficiente e rápido.
Repetibilidade: Os testes devem ser repetíveis, para que os resultados possam ser verificados com confiança (testes independentes).

Estrutura em camadas

Uma estrutura de testes de API em camadas, pode te ajudar a atingir esses objetivos, pois ele divide os testes em diferentes camadas, cada uma com uma responsabilidade específica.

A Arquitetura em camadas é um estilo arquitetural que dentre vários objetivos, o maior dele é organizar as responsabilidades de partes de um software, normalmente criando um isolamento e dando um propósito bem definido a cada camada de forma que a mesma possa ser reutilizável por um nível mais alto ou até substituível. O uso desse conceito é até antigo, amplamente utilizado a algum tempo, porém essa motivação de traze-lo para automação de testes foi devido a grande desorganização nas aplicações corporativas que ja trabalhei, que se perderam em meio a troca de profissionais, descontinuação de uma stack ou até mesmo a reescrita de um mesmo teste com tecnologias diferentes (Sim, existem profissionais que sabem apenas uma ferramenta, e usam a qualquer custo).

Exemplo:

Uma camada física, pode ser convertida em várias camadas lógicas para organizar e traçar responsabilidades de uma aplicação backend.

Então como poderíamos trazer isso para automação dos testes de API? Para isso vamos pensar em um modelo básico, que não necessariamente será o mesmo em todos os casos, mas possuem características semelhantes.

Data

Essa camada é pensada justamente na forma que estamos abstraindo a construção de objetos que usamos em nossas requisições. Um grande ponto de atenção que percebo, é que a maioria dos projetos o payload é criado dentro do teste, ou na camada que realiza a requisição. Isso cria um acoplamento desnecessário e prejudica a manutenção do código, dado que precisa alterar o código em vários pontos em sua manutenção.

Então como podemos abstrair isso?

Simples, basta usarmos uma classe simples que retorna um objeto de acordo com seu construtor ou método que retorna ele para sua classe. O ideal é sempre passar o payload (ou body) como parâmetro da sua requisição.

No exemplo acima é apenas uma abstração de uma classe que por sua vez possui um método new_user_payload que retorna o objeto user para uma requisição do tipo POST create_user então, eu deleguei para a classe DataUser a responsabilidade de criar um objeto.

A Princípio isso pode parecer simples, mas a manutenção do código passa a ser simplificada uma vez que a criação do objeto é concentrada em uma classe, sem a necessidade de repetir o objeto no corpo do teste.

Requests

Esta camada é mais comum vê-la abstraída de forma correta, mas nem sempre é seguida uma boa prática em sua utilização.

Uma vez definido que uma classe irá retornar o resultado de uma requisição Response então vamos definir essa responsabilidade única para suas funções

Repare que a classe UserRequests dispõe funções que retornam o resultado das requisições, e recebe por parâmetro o payload (body) ou outros argumentos necessários, para tornar mais genérica sua chamada. Isso fará que sua classe tenha um reuso dentro dos testes.

Setup

Em alguns testes e frameworks, sempre temos a necessidade de abstrair algum dado que não pode ficar hard coding na aplicação, isso tudo porque precisamos realizar alterações nesse valor para deixar nossos testes repetíveis em várias situações.

A mais comum são as trocas de ambientes (de desenvolvimento para homologação para produção, etc..)

Então essas classes ou configurações são responsáveis por garantir que essas informações sejam carregadas de acordo com a necessidade dos nossos testes.

Um bom exemplo, é a base_uri das nossas API's que podem mudar de acordo com o ambiente.

Neste exemplo eu salvei a informação da ninha url base no arquivo .env que por sua vez é inicializada através da classe SetupClass que retorna o valor contido na variável BASE_URL. Ja nas classes responsáveis por realizar as requisições eu apenas retorno para o ENDPOINT o valor dessa configuração.

Devemos evitar ao máximo realizar o hard coding em nossos projetos, eles normalmente dificultam a manutenção e podemos até mesmo quebrar os testes quando não nos atentamos a estas alterações.

Importante

Essa maneira de organizar o seu código não é única e exclusiva, mas a iniciativa é exemplificar o quanto um código pode ficar organizado seguindo esse modelo. E por vezes quando mudamos de linguagem ou framework, são disponibilizadas recursos diferentes para as mesmas configurações, então o foco não deve ser em uma linguagem ou ferramenta ok?

Conclusão

A busca por deixar nossos projetos de automação cada vez mais robustos e reaproveitáveis nos leva a pensar em diferentes maneiras de organizar nosso código, quando estamos desenvolvendo de forma colaborativa, a quantidade de conflitos que podemos ter em nossos repositórios sempre são grandes, dado a quantidade de acoplamento que criamos sob nossas automações.

A principal motivação é que este post lhe faça refletir sobre como podemos disponibilizar nosso código de forma objetiva e fácil manutenção e que suas abstrações façam o papel de ajudar a legibilidade do código e não aumente a complexidade de aprendizado.

Deixo aqui um repositório com vários boilerplates do mesmo projeto de automação de API com diferentes linguagens e frameworks que trabalham a mesma ideia.

rafaelbercam / boilerplates

Test automation project boilerplates

Boilerplates Testes Automatizados

O que são?

Em programação de computadores, código boilerplate ou boilerplate se refere a seções de código que devem ser incluídas em muitos lugares com pouca ou nenhuma alteração.

Traduzindo em poucas palavras: é um código padrão ou esqueleto de um código no qual poderá ser reutilizado com pouca alteração ou nenhuma para dar start nos projetos.

Seções

Testes API

Testes Web

Testes Mobile

Automação de Testes Mobile com WebdriverIO

Web Crawler

Alerta de Preço com Puppeteer

View on GitHub

E não deixe de compartilhar este post e deixar um comentário ou dúvida! Minha intenção é compartilhar um pouco do meu conhecimento!

Até a próxima!

Meus links

Resolvendo variáveis de ambiente em testes automatizados com dotenv

Rafael Berçam — Fri, 02 Jul 2021 16:56:49 +0000

O Problema

Sempre é uma questão recorrente de, como utilizar variáveis de ambiente em testes automatizados? Como remover do código credenciais de acesso, urls de acesso ao sistema e diminiur a vulnerabilidade?

Isso é extremamente importante quando o assunto é segurança dos seus repos (mesmo privados), então o que me motivou a criar este post é mostrar como fazer isso usando recursos simples, disponíveis na maior parte das linguagens e frameworks de mercado.

Variáveis de ambiente, o que são?

Uma variável de ambiente possui um valor recebido de forma dinâmica, que pode afetar a forma em que os processos em execução se comporta no sistema operacional.

Trocando seis por meia dúzia, são variáveis que em tempo de execução recebem valores definidos de forma dinâmica, podendo customizar o valor de acordo com o ambiente executado.
Um bom exemplo são ambientes de execução como Dev, Homolog e Produção, ou credenciais de acesso nesses diferentes ambientes como email e senha.

E quais são os riscos de deixar isso no repositório?

Pode ser até uma pergunta fácil de responder, mas os riscos variam de acordo com o sistema em que você atua.

Imagine um ambiente que comumente é atacado e explorado sua vulnerabilidade? Qualquer brecha é um risco para que exponha dados sensíveis para o mundo externo. Mesmo em repositórios privados, tem o fator humano que pode expor propositalmente e complicar a vida de um time inteiro.

Então sem mais delongas, vamos ver como resolver isso dentro dos códigos e quais soluções de mercado temos para isso.

.ENV

Dentro do ecossistema JavaScript, temos o dotenv que é uma lib muito comum e fácil de usar.

vamos analisar o seguinte trecho de código:

describe("Teste recurso /login", async ()=>{
    it("login com sucesso", async ()=>{
        credentials = {
            "email":"fulano@qa.com",
            "password":"teste"}
        response = await postLogin(credentials);
        expect(response.statusCode).to.eq(200);
        expect(response.body.message).to.eq(
            "Login realizado com sucesso");
    })
})

Pois bem, as credenciais de acesso estão expostas no código, e podem ser facilmente identificadas pelos termos de pesquisa de código como password, email.

Em um sistema operacional como o Linux, quando precisamos atribuir um valor a uma variável de ambiente em tempo de execução, usando o comando:

export VARIAVEL='valor-da-variavel'

E para imprimir o valor e conferir o seu armazenamento podemos usar o comando

echo $VARIAVEL
// valor-da-variavel

vide exemplo abaixo

Considerando essa informação, vamos fazer um teste com nosso trecho de código onde vou substituir os valores que estão expostos por variáveis de ambiente em tempo de execução. Para isso vamos usar o process.env.

O process.env é um recurso do próprio do node de pegar as variáveis de ambiente do sistema.
Se usarmos o mesmo teste do terminal imprimindo apenas as variáveis de ambiente do SO usnado o process.env do node.js.

Ao começar a digitar o process.env no node, o terminal já exibe previamente uma lista de variáveis que o sistema disponibiliza. Essas variáveis são definidas previamente quando ligamos o computador e damos o arranque no sistema operacional, para isso ele pega as variáveis de ambiente definidas em arquivos específicos.

Exemplo: ~./bashrc do Linux

Quando exportamos uma variável como mostra no comando da imagem acima, elas ficam disponíveis enquanto o terminal está em execução, então essas variáveis são listadas quando imprimimos:

vide saída do comando process.env

Então, vamos fazer um teste: Antes de executar o mesmo trecho de código vou substituir os valores por process.env.EMAIL e process.env.PASSWORD e executar o código.

describe("Teste recurso /login", async ()=>{
    it("login com sucesso", async ()=>{
        credentials = {
            "email":`${process.env.EMAIL}`,
            "password":`${process.env.PASSWORD}`}
        response = await postLogin(credentials);
        expect(response.statusCode).to.eq(200);
        expect(response.body.message).to.eq(
            "Login realizado com sucesso");
    })
})

Executando o comando para realizar o teste exportando as variáveis:

"test-dev": "export EMAIL='fulano@qa.com' && export PASSWORD='teste' &&  mocha --file login-test.js",

Obtive sucesso no teste

Então precisamos exportar sempre? Claro que não!

Vamos utilizar uma lib popular que ja mencionei que se chama dotenv. Para isso, use o comando de instalar a dependência dotenv no seu projeto usando o gerenciador de dependências

Exemplo: yarn add dotenv ou npm install dotenv

Após a instalação, crie um arquivo na raiz do projeto .env contendo os valores das variáveis de ambiente.

Crie as variáveis de ambiente, contendo todas as informações que precisa abstrair do sistema para as variáveis de ambiente.

Agora na classe de testes, vamos substituir os valores das credenciais por variáveis de ambiente. E também vamos importar o arquivo .env para dentro da classe de testes.

import * as dotenv from 'dotenv'
dotenv.config({ path: '../../.env' });



describe("Teste recurso /login", async ()=>{
    it("login com sucesso", async ()=>{
            credentials = {
                email: `${process.env.EMAIL}`,
                password: `${process.env.PASSWORD}`
            }
            console.log(credentials);

        response = await postLogin(credentials);
        expect(response.statusCode).to.eq(200);

    })
})

Repare que no código estou imprimindo as credenciais para ter certeza que o valor esta sendo atribuído para as variáveis de ambiente.

Executando o teste então temos:

Veja como é simples!
Agora tem uma dica importante. Precisamos adicionar no .gitignore o arquivo .env e criar um arquivo de exemplo para quem foi baixar o seu repositório, saiba que precisa cria-lo para expor as variáveis de ambiente.

Concluindo

Este foi um exemplo simples de configuração, lembrando que existem maneiras mais abstratas e combinadas com uso de outras libs como cross-env

Aqui estão os repositórios oficiais do dotenv e cross-env

Neste repositório, eu utilizo os mesmos recursos deste post!

rafaelbercam / api-tests-typescript

Automação de Testes de API com TypeScript

Boilerplate Testes de API em TypeScript

Pré-requisitos

Instalar o Node

Ambiente

Para executar os testes localmente, estou utilizando o ServeRest

Link do Repo: https://github.com/ServeRest/ServeRest

ServeRest está disponível de forma online, no npm e no docker.

Instalando Dependências

Rodar o comando

npm i

Criar arquivo .env na raiz do projeto

Criar o arquivo com as seguintes variáveis

PROD=https://serverest.dev
DEV=http://localhost:3000

Rodar os testes localhost

npm run test-dev

Para rodar os testes em Produção

npm run test-prod

Configuração do Projeto

Estrutura de Pastas

O projeto esta dividido da seguinte maneira:

[api-tests-typescript]
   [src] -> código fonte
        [config] -> arquivos de configuração ambiente
        [factory] -> métodos para criar objetos
        [services] -> funções que retornam requisições das rotas
        [test] -> Arquivos de testes com Mocha e Chai.
   .env -> arquivo com variáveis de ambiente(normalmente não commitada)
   .mocharc.js -> arquivo de configuração do Mochawesome

Services

Services são funções que retornam requests pré-estabelecidas de cara um…

View on GitHub