Testes Automatizados no Currículo: O Termo Que Mais Falta em Dev

Dev que escreve testes em toda funcionalidade e nunca os lista no currículo deixa de fora uma parte do que sabe fazer. Testes automatizados no currículo ganham peso quando você nomeia o tipo (unitário, de integração ou end-to-end), a ferramenta do seu stack e o lugar onde os testes rodam, como o pipeline de integração contínua. Este guia mostra como escrever cada parte sem inventar números e sem transformar a linha numa lista de ferramentas.

Quais tipos de teste automatizado você escreveu?

Três tipos aparecem na maioria das vagas de desenvolvimento, e cada um testa uma coisa diferente. Escreva o tipo que você de fato produziu, porque a vaga pode pedir qualquer um dos três pelo nome.

• Testes unitários. Testam uma função ou classe isolada, com as dependências substituídas por dublês. São rápidos e costumam formar a maior parte de uma suíte.
• Testes de integração. Testam dois ou mais componentes juntos, como o serviço de pedidos falando com o banco de dados. Pegam o erro que o teste unitário não vê, como uma consulta que devolve colunas trocadas.
• Testes end-to-end. Percorrem o fluxo como um usuário faria, no navegador ou na API completa, como cadastrar, comprar e receber a confirmação. São os mais lentos e os que mais se aproximam do trabalho de QA.

Se você escreveu só testes unitários, não liste os três. Diga o que fez, com o nome do tipo, e explique o que eles cobrem.

Antes: Escrevo testes automatizados em todos os projetos.

Depois: Escrevo testes unitários das regras de cálculo de frete e testes de integração do serviço de pedidos com o PostgreSQL em container, rodados a cada commit.

Quais ferramentas escrever e como ligá-las ao seu stack?

Escreva a ferramenta que roda no seu projeto, ao lado do tipo de teste, porque o nome sozinho não diz onde ele foi usado. A lista abaixo mostra como casar ferramenta e stack, e não é um inventário para copiar.

• Jest ou Vitest para unitários e de componentes em JavaScript e TypeScript, com a biblioteca de testes de componentes que o projeto usar.
• JUnit com Mockito para Java, com os dublês de dependência descritos pelo nome da biblioteca.
• Pytest para Python, com fixtures que sobem o banco de teste antes da suíte de integração.
• Cypress ou Playwright para end-to-end no navegador, com o fluxo que cada um percorre.

Antes: Testes com Jest, JUnit e Cypress.

Depois: Cubro com Jest as regras de precificação do checkout e com Cypress o fluxo de pagamento por cartão, rodados no pipeline a cada pull request.

A segunda versão diz o que cada ferramenta testa. A primeira lista três nomes e deixa o recrutador adivinhar se algum deles foi usado de verdade.

Onde os testes rodam, e por que essa linha prova que eles são reais?

Um teste que roda só na máquina de quem escreveu não protege o time. Diga em qual etapa do pipeline ele roda, como integração contínua no GitHub Actions, GitLab CI ou Jenkins, e se a falha bloqueia o merge, quando isso estiver configurado no projeto.

Antes: Experiência com testes e integração contínua.

Depois: Mantive a suíte de testes de integração no GitHub Actions, executada em cada pull request, com o merge bloqueado quando algum teste falhava.

Se você não configurou o pipeline, escreva o que fez dentro dele, como manter os testes verdes ou corrigir uma etapa que quebrava, e não a configuração inteira.

Cobertura: escreva o escopo, e não um percentual que você não mediu

Percentual de cobertura é um número que a ferramenta calcula. Só vale citá-lo se você o viu num relatório do projeto. Um número inventado é a primeira coisa que uma conversa técnica desfaz. Quando não há número, descreva o escopo: quais módulos têm teste e quais fluxos o end-to-end cobre.

Antes: Cobertura de testes acima de 90%.

Depois: Testes unitários cobrindo as regras de cálculo do módulo de pagamentos, com o relatório de cobertura do Jest no pipeline, e testes end-to-end para o cadastro e o checkout.

Se a vaga é de QA ou pede automação como função principal, o caso de cobertura e de ferramentas tem mais detalhe no guia de currículo de analista de QA. Este guia fica com o desenvolvedor que escreve os próprios testes.

Onde mostrar os testes que você escreveu quando a vaga pede um teste técnico?

O teste automatizado é o argumento mais forte de um desenvolvedor em uma seleção técnica, porque mostra código que ele pode abrir e discutir. Se a vaga tem um teste prático, use a mesma lógica no currículo: um repositório público com a suíte e um README curto que diga o que é coberto e como rodar.

Quando a seleção pede uma tarefa para casa, o que se avalia costuma ser se o candidato testou o próprio código. O funcionamento dessa etapa está no guia de teste prático no processo seletivo, e vale lê-lo antes de montar o repositório de exemplo.

O que escrever se você nunca montou uma suíte própria?

Não escreva testes automatizados se não os escreveu. Descreva o que de fato fez para validar o código, como revisar pull requests com foco nas regras, reproduzir um bug e cobri-lo com um teste de regressão ou testar uma tela manualmente antes de cada entrega. Essas atividades têm valor próprio e não precisam fingir uma suíte.

Para ganhar a prática, monte um projeto pessoal pequeno: uma API com duas ou três regras, testes unitários dessas regras, um teste de integração com um banco de teste e a suíte rodando num pipeline. Descreva-o como projeto pessoal, com o stack e o que ele testa. Uma linha dessas, com um repositório que roda, pesa mais do que um curso citado sozinho. Se o projeto é uma API, as camadas dela aparecem no guia de currículo de desenvolvedor back-end, com a forma de descrevê-las.

Quais linhas de teste conferir antes de enviar?

A regra central é que toda menção a teste automatizado tenha tipo, ferramenta e onde roda, e que cada uma corresponda ao que você fez. Uma linha assim mostra que você entende a diferença entre os tipos e não depende de uma palavra genérica. Sem esses detalhes, o currículo diz que o candidato testa, e a primeira pergunta técnica mostra o que ele de fato sabe.

Para conferir se o seu texto cobre o que a vaga pede, cole o anúncio e o currículo na análise gratuita do AjustaCV. Ela não exige cadastro e mostra quais termos da vaga já aparecem no seu currículo e quais ainda faltam.

Perguntas frequentes