Uma alteração pequena, uma lembrança esquecida
Alguém corrige uma regra na Cantina Horizonte, faz commit e envia a mudança para o GitHub.
Os testes existem, mas ninguém os executou antes do envio.
Ter testes automatizados ajuda muito. Porém eles só protegem o projeto quando realmente são executados.
E se o próprio fluxo de trabalho disparasse os testes?
Esse tipo de prática faz parte da Integração Contínua.
Continuous Integration (CI) — Integração Contínua
CI é a prática de integrar mudanças com frequência e executar verificações automáticas para descobrir problemas cedo. Os testes são uma parte importante dessas verificações.
CI não é o nome de uma ferramenta específica. É uma prática. Diferentes ferramentas podem executá-la.
No nosso projeto, quem executará o processo é o GitHub Actions
GitHub Actions
É o recurso do GitHub que permite executar tarefas automáticas quando determinados eventos acontecem no repositório, como um push ou uma Pull Request.
Pull Request (PR) é o pedido de integração de alterações de uma branch em outra. Você já conhece esse fluxo no Mundo bit Byte; aqui ele passa a ganhar também verificações automáticas.
O arquivo que descreve o processo
A Cantina Horizonte agora possui:
.github/workflows/qts-cantina-horizonte.ymlA extensão .yml é usada para arquivos escritos em YAML. O nome YAML é um acrônimo recursivo de YAML Ain't Markup Language. Na prática, aqui basta entendê-lo como um formato textual muito usado para configurações.
Não precisamos estudar toda a sintaxe agora; precisamos conseguir ler a sequência de trabalho.
Faça esta prática em uma cópia sua
Não faça alterações de aula no repositório oficial do Mundo bit Byte. Use uma cópia do repositório em sua conta ou o repositório indicado pelo professor.
Essa cópia precisa manter a pasta qts/cantina-horizonte-v1 e o arquivo .github/workflows/qts-cantina-horizonte.yml, porque o workflow usa esses caminhos.
- Envie sua branch de exercício ao GitHub.
- Abra a aba Actions do seu repositório.
- Procure o workflow QTS - Cantina Horizonte.
- Abra a execução mais recente e observe cada etapa.
Leia o pipeline como uma receita
Pipeline é uma sequência automatizada de etapas. No nosso caso:
| Etapa automática | O que acontece |
|---|---|
| Baixar o projeto | O GitHub Actions obtém os arquivos daquela versão. |
| Preparar Python | Cria o ambiente para executar o backend e os testes. |
| Instalar dependências | Instala FastAPI, pytest e demais pacotes definidos. |
| Executar pytest | Roda os testes Python e apresenta a cobertura. |
| Preparar Node.js | Cria o ambiente usado pelo Playwright. |
| Instalar Chromium | Disponibiliza o navegador necessário ao E2E. |
| Executar E2E | Abre o sistema e percorre o fluxo automatizado. |
Verde e vermelho ganham outro significado
Se todas as etapas terminarem corretamente, a execução aparece como concluída com sucesso. Se um teste falhar, a execução fica marcada como falha.
Verde significa que as verificações configuradas passaram naquela execução.
Isso é útil, mas não significa “o software não possui defeitos”. O pipeline só sabe verificar aquilo que foi configurado para verificar.
Faça uma pequena experiência controlada
Na sua cópia do projeto, altere temporariamente:
return 1 <= quantidade <= 10para:
return 1 <= quantidade < 10Agora a quantidade 10 deixa de ser aceita. Faça commit e push na branch de exercício.
O teste que protege o limite superior deve falhar. Na aba Actions, abra a nova execução e localize a etapa que ficou vermelha.
Depois restaure <= 10, faça novo commit e push e observe a nova execução. Ela deve voltar a ficar verde se nenhuma outra verificação falhar.
Por que isso é diferente de executar pytest no seu computador?
Executar localmente continua sendo importante. A diferença é que o CI fornece uma verificação repetível em um ambiente preparado automaticamente e ligada ao histórico da alteração.
Assim, a equipe não depende apenas da frase:
“Na minha máquina passou.”
A cobertura também pode aparecer no pipeline
Nosso fluxo executa:
pytest --cov=backend --cov-report=term-missingIsso mostra quais partes do backend foram exercitadas pelos testes. Novamente: cobertura é informação para investigação, não certificado de qualidade.
Nem todo teste precisa rodar da mesma forma em todo projeto
Testes unitários costumam ser rápidos. Testes E2E podem levar mais tempo e depender de mais componentes.
Projetos maiores podem organizar diferentes conjuntos de testes em momentos diferentes. Aqui mantemos um único pipeline simples porque o objetivo é compreender o princípio sem esconder o aprendizado atrás de uma infraestrutura complicada.
A espiral volta ao processo
Lá no início, a equipe testava quando lembrava. Depois surgiram casos, registros, regressão, automação e agora uma execução automática ligada às mudanças.
Essa evolução ajuda a tornar o processo mais consistente e menos dependente de memória individual.
Agora voltamos à pergunta inicial
Temos requisitos, técnicas, riscos, plano, casos, evidências, registros de defeito, testes automatizados, API, E2E e CI.
Mas nenhuma dessas coisas, isoladamente, responde por nós:
A versão atual está pronta para entrega?
Antes de seguir
Você deve conseguir explicar:
- o que significa Integração Contínua (CI);
- a diferença entre CI e GitHub Actions;
- o que é um pipeline;
- por que um pipeline verde não prova que o software é perfeito;
- como a execução automática reduz a dependência da memória da equipe.