Módulo 4: Dados e CI

Mil requisições com o mesmo email, o mesmo produto, o mesmo usuário batem sempre no mesmo registro: cache quente, um lock só, um caminho de código. O sistema parece mais rápido do que é. Carga séria usa dados variados e reaproveita o que a resposta devolve.

🧩 trecho de exemplo: JavaScript pra estudar ou colar num arquivo .js, não é comando de terminal

import { SharedArray } from "k6/data";

// open() so funciona no contexto de init (fora da funcao default).
const usuarios = new SharedArray("usuarios", function () {
  return JSON.parse(open("../dados/usuarios.json"));
});

export default function () {
  const u = usuarios[(__VU - 1) % usuarios.length];  // um usuario por VU
  // ... usa u.usuario, u.email
}

Sem SharedArray, cada VU carregaria o arquivo inteiro na memória. Com ele, a lista é lida uma vez e compartilhada. O padrão (__VU - 1) % tamanho distribui os usuários entre os VUs de forma circular.

🧩 trecho de exemplo: JavaScript pra estudar ou colar num arquivo .js, não é comando de terminal

// 1) login devolve um token
const login = http.post(`${BASE}/login`,
  JSON.stringify({ usuario: u.usuario, email: u.email }),
  { headers: { "Content-Type": "application/json" } });
const token = login.json("token");        // <- extrai da resposta

// 2) o proximo passo precisa desse token
const email = `${u.usuario}+${__ITER}@teste.com`;   // muda a cada iteracao
http.post(`${BASE}/pedidos`,
  JSON.stringify({ itens: [{ produto_id: 1, quantidade: 1 }], email }),
  { headers: {
      "Content-Type": "application/json",
      Authorization: `Bearer ${token}`,   // <- reaproveitado aqui
  } });

Isso é correlação: token de sessão, id de pedido recém-criado, CSRF token, ou seja, qualquer valor que o servidor gera e espera de volta no passo seguinte. __ITER é o número da iteração; usar ele no email garante um valor novo a cada volta.

scripts/04_dados.js junta as duas coisas: usuário da lista, login → token, email único por iteração.

Se você encerrou o mock com Ctrl+C no módulo anterior, suba ele de novo no Terminal 1 antes de continuar:

python mock/servidor.py

Com o mock ligado, no Terminal 2:

k6 run scripts/04_dados.js

Agora vá ao Terminal 1 e aperte Ctrl+C pra encerrar o mock. Sem isso o corretor não consegue ler o relatório do servidor. Só depois disso, de volta no Terminal 2:

python verificar.py 4

O corretor lê o relatório do mock e confere: emails_distintos alto (o dado variou), tokens_reaproveitados > 0 (a correlação funcionou), tokens_distintos = 10 (todos os usuários da lista entraram).

O mesmo teste que você roda na mão pode rodar a cada push. O workflow .github/workflows/trilha-5-k6.yml já vem pronto no projeto. Isto aqui é só pra você ver o conteúdo, não precisa copiar nem colar no terminal:

📄 .github/workflows/trilha-5-k6.yml (trecho), não cole no terminal

      - name: Instalar o k6
        uses: grafana/setup-k6-action@v1

      - name: Subir o servidor-alvo (mock) em segundo plano
        working-directory: trilha-5
        run: |
          python mock/servidor.py &
          # ... espera a porta responder

      - name: Rodar o smoke (tem que passar limpo)
        working-directory: trilha-5
        run: k6 run scripts/01_smoke.js

      - name: Rodar a carga (portao de performance)
        working-directory: trilha-5
        run: k6 run scripts/03_carga.js

Se um threshold reprovar, o k6 run sai com código 99, o step falha e o build fica vermelho. Como o 03_carga.js tem a meta apertada de propósito, esse job já nasce vermelho: é o portão funcionando. Na vida real você calibra a meta pro que o sistema cumpre e ela passa a te avisar quando uma mudança piora a performance.

Rode 04_dados.js, encerre o mock e rode python verificar.py 4, confirme os 5 [ok]. Depois troque iterations: 100 por iterations: 300 e confira que emails_distintos no mock/ultimo_relatorio.json cresce junto (com email fixo, esse número travaria: é o sinal de dado repetido). Gabarito em trilha-5/GABARITO.md.

Você tem o ciclo completo: escrever o roteiro, definir a meta como threshold, desenhar a rampa, variar o dado, e pôr no CI como portão. O próximo passo natural é apontar esses scripts pra um ambiente de homologação de verdade (trocando o BASE_URL) e calibrar as metas com o time.

Olhar de QA

Portão de performance mal calibrado é pior do que não ter: o time aprende a ignorar o vermelho, e aí o sinal some justamente no dia em que importa. Meça primeiro, coloque o limite com folga sobre o que você observou, prefira percentil a máximo, e combine explicitamente com o time que o vermelho barra a entrega. Um portão só vale se alguém realmente para quando ele fecha.