Testes depuração versões e primeiro ciclo completo

Transformar uma expectativa em verificação

Um teste executa um cenário e compara o resultado observado com uma expectativa. A expectativa precisa vir da regra, e não de copiar o resultado que o programa já produziu. Para a função de títulos, esperamos que um inativo fique de fora e que a entrada permaneça intacta. Um erro que alterasse os dados poderia passar em um teste que só observa o primeiro título.

O arquivo 06_funcoes.test.mjs usa o executor de testes incluído no Node. Não exige instalar uma biblioteca de testes. test organiza um cenário, e assert verifica uma condição. O nome do teste descreve o comportamento protegido. Leia a lista antes de executar para saber o que uma aprovação realmente cobre.

Uma suíte pequena explicada

import test from 'node:test';
import assert from 'node:assert/strict';
import { selecionarTitulos } from './04_funcoes.mjs';

test('lista somente títulos ativos e preserva a entrada', () => {
  const casos = [
    { titulo: 'A', ativo: true },
    { titulo: 'B', ativo: false }
  ];
  const antes = structuredClone(casos);
  assert.deepEqual(selecionarTitulos(casos), ['A']);
  assert.deepEqual(casos, antes);
});
test('lista vazia é aceita', () => {
  assert.deepEqual(selecionarTitulos([]), []);
});
test('entrada que não é lista é rejeitada', () => {
  assert.throws(() => selecionarTitulos(null), TypeError);
});

deepEqual compara a estrutura e os valores das coleções; comparar dois arrays com === verificaria se são o mesmo objeto, não se contêm os mesmos itens. structuredClone cria uma cópia para verificar o estado anterior. throws exige que a chamada fornecida lance o tipo de erro indicado. A função passada ao teste adia a execução da chamada até o momento da verificação.

node --test 06_funcoes.test.mjs

O resultado esperado é a aprovação dos três testes. O formato exato da apresentação pode variar com a versão e a configuração do executor. Leia os nomes e a contagem e confira o código de saída. Uma suíte aprovada não prova o contrato completo do catálogo; prova os cenários definidos para esta função simplificada.

Investigar uma falha com hipótese

Mude temporariamente a condição da função para caso.ativo === false. Execute a suíte sem alterar o resultado esperado. O primeiro teste deve falhar porque a regra de seleção foi invertida. Restaure true e execute novamente. Agora a aprovação tem um significado adicional: o teste demonstrou capacidade de detectar aquele defeito.

Esse percurso fornece proteção de regressão para uma mudança: conservar verificações que identificam o comportamento indesejado caso ele volte. Regressão não é um nível de teste separado. Pode haver proteção de regressão em funções isoladas, na integração HTTP e na interface completa.

Quando um teste falha, leia primeiro qual cenário falhou, depois a diferença entre esperado e recebido. Reproduza com o menor conjunto de entradas suficiente para explicar o problema. Não apague uma asserção só para obter uma saída verde. Se a regra mudou legitimamente, registre a nova decisão e acrescente cenários que mostrem o antes e o depois.

Guardar versões que uma pessoa consegue comparar

Git registra versões de arquivos e permite comparar alterações. Um commit representa um estado identificado do repositório. Um diff mostra diferenças entre versões ou entre o arquivo atual e um estado registrado. Git não é o mesmo serviço que GitHub; os comandos locais podem ser usados sem publicar o trabalho.

Se Git estiver instalado, faça o exercício em uma cópia da pasta laboratorios_iniciais. Inicialize o repositório, examine os arquivos e registre uma versão somente após revisar o que será incluído. Configure sua autoria conforme as instruções do Git se o programa solicitar; não há identidade fictícia obrigatória nesta atividade.

git init
git status
git add 01_primeiro.mjs 04_funcoes.mjs 06_funcoes.test.mjs
git diff --staged
git commit -m "Registra primeiros laboratórios"

Depois de alterar uma linha, git diff mostra a mudança ainda não registrada. O histórico ajuda a recuperar código, mas não resolve sozinho exposição de uma credencial: apagar a linha atual não invalida um token já divulgado. Os capítulos de segurança tratam a resposta apropriada a esse evento.

Executar a Oficina Caracol e fechar o ciclo

Entre na pasta pratica do pacote. Leia seu README e execute npm ci, npm test e npm run validate. O primeiro prepara o ambiente conforme o manifesto e o lockfile; neste projeto não há dependências externas. O segundo verifica cenários automatizados. O terceiro reúne sintaxe, contrato de dados e testes. Um comando existir em package.json não prova sua aprovação: leia o resultado de sua execução.

npm ci
npm test
npm run validate
npm start

Com o servidor em execução, abra http://127.0.0.1:3000. O terminal permanece ocupado pelo processo; Control+C o encerra. Em outro terminal, você pode executar testes. A reserva é uma simulação em memória e não efetua pagamento, agenda real ou armazenamento durável. Reiniciar o processo perde esse estado. Snapshot e restore pertencem exclusivamente ao laboratório de recuperação em sandbox.

Exercício final: altere o título de um caso ativo na cópia de trabalho, valide os dados, execute os testes e observe a interface. Entregue o diff, o comando, o resultado e o limite do que conferiu. Solução de referência: o título muda, os identificadores continuam estáveis, inativos continuam omitidos e os testes aplicáveis passam. Se a interface não foi observada, registre essa lacuna em vez de declarar o fluxo visual aprovado.

Ao concluir esses passos, você já percorreu uma primeira unidade Caracol: formulou uma mudança, delimitou arquivos, implementou, verificou, registrou evidência e decidiu a próxima ação. Os capítulos seguintes aprofundam como organizar essa prática em projetos com mais pessoas, dados e risco.