AI coding: tests/review/segurança
Assistência de IA pode acelerar testes, review e investigação de logs, mas essas tarefas têm funções diferentes. Testes verificam comportamentos; review procura problemas no desenho e no diff; logs mostram eventos observados. Nesta aula você construirá uma avaliação complementar, evitando tomar uma aprovação textual como prova.
O caso é uma importação de pedidos. Ela deve rejeitar entradas inválidas, não vazar dados e processar arquivos com limites conhecidos. Essa tarefa também permite discutir terminal, permissões e paralelismo: agentes podem investigar partes independentes, mas a integração exige um responsável e contratos claros.
JavaScriptIA & MLSegurançaAvaliaçãoProgramaçãoAo terminar esta aula
- Testes, review e logs fornecem evidências diferentes.
- Paralelismo precisa de limites e integração.
- Permissões concretas valem mais que promessas no prompt.
Antes de continuar: Laboratório: AI coding: exploração/refactor/debug
Testes gerados precisam observar o requisito
AvaliaçãoUm teste útil falha quando um comportamento importante está errado. O assistente pode sugerir casos, mas você precisa verificar se expectativas vêm do requisito ou apenas reproduzem a implementação. Um teste que calcula esperado com a mesma função testada tende a confirmar o próprio código. Para importação, casos relevantes incluem campo ausente, valor negativo, duplicata e arquivo vazio. Cada caso deve ter resultado explícito e uma razão ligada ao contrato.
Testes unitários isolam regras; integração verifica fronteiras entre módulos; E2E observa jornadas do usuário. Playwright recomenda testes independentes e seletores orientados ao comportamento percebido, reduzindo fragilidade acidental. Um teste E2E não precisa inspecionar todos os detalhes internos. Para importação, verifique arquivo enviado, confirmação e resultado visível. Preserve casos de erro e acessibilidade da interação. A IA ajuda a ampliar hipóteses, mas a cobertura relevante é uma decisão do produto e da engenharia.
Code review e análise de vulnerabilidades
FundamentosReview examina o que mudou, por que mudou e que efeitos pode causar. Peça ao assistente conclusões com localização, cenário e consequência. “Pode estar inseguro” sem um caminho de entrada e efeito é uma hipótese vaga. No importador, avalie validação, limites de tamanho, autorização e tratamento de dados. Uma função que aceita tenantId do arquivo como autoridade pode permitir importar pedidos para outro cliente, mesmo se todos os tipos forem válidos.
↗ Common workflows↗ Safety in building agents↗ GitHub Copilot on GitHub.com
Análise de vulnerabilidades precisa distinguir evidência de suspeita. Conteúdo de código, dependências e configuração ajudam, mas ausência de alerta não prova segurança. Confirme o cenário com teste controlado quando possível, sem atacar serviços reais. Evite pedir ao agente uma aprovação geral de um repositório que ele leu parcialmente. Revise também os testes adicionados: um teste que confirma comportamento vulnerável pode parecer uma garantia. O review complementa execução e análise estática, não substitui ambos.
↗ Common workflows↗ Safety in building agents↗ GitHub Copilot on GitHub.com
Logs úteis e dados sensíveis
FundamentosUm log registra um evento específico e precisa de contexto para explicar uma falha. No importador, inclua identificador de lote, etapa, número de registros, duração e código de erro. Evite gravar documento integral, tokens de autenticação e dados pessoais apenas para facilitar debugging. Se detalhes forem indispensáveis, restrinja acesso e retenção. Um assistente que recebe logs também recebe seus dados; a escolha do serviço e o escopo da entrada fazem parte do desenho.
Ao analisar, construa uma linha temporal e correlacione eventos da mesma execução. Uma mensagem de erro tardia pode esconder a origem anterior. Diferencie “não há evento” de “o evento não aconteceu”: a instrumentação pode ser incompleta. Peça hipóteses que possam ser verificadas. Se o modelo afirma que um timeout causou duplicatas, procure a tentativa repetida e o identificador do lote. Não ajuste retries apenas porque o log contém essa palavra.
Tarefas paralelas e subagentes
FundamentosParalelismo ajuda quando tarefas têm entradas e artefatos independentes. Uma pessoa ou agente pode revisar validação, outro pode criar casos de arquivo vazio e um terceiro pode inspecionar a interface. Defina escopo, saída esperada e arquivos autorizados. Se todos editam a mesma função ao mesmo tempo, surgem conflitos e hipóteses incompatíveis. A integração exige verificar o resultado combinado, não apenas somar relatórios de sucesso.
Subagentes podem trabalhar com contexto próprio e devolver descobertas ou alterações segundo o produto. Isso não garante coordenação automática nem elimina custo. Uma tarefa mal definida pode ser executada em paralelo com a interpretação errada. Peça evidências e limites no retorno: o que foi lido, alterado e verificado. Um coordenador precisa conferir dependências e revisar sobreposições. Para tarefas pequenas e fortemente acopladas, execução sequencial pode ser mais simples e verificável.
Terminal, sandbox e permissões
FundamentosTerminal oferece capacidades amplas: ler, escrever, executar e comunicar com rede. Um comando aparentemente de teste pode acionar scripts do projeto com efeitos externos. Leia scripts e configuração antes de conceder execução ampla. Sandbox limita capacidades conforme o ambiente; aprovação decide se uma ação pode ser autorizada. Os mecanismos variam entre produtos. Não presuma que “modo seguro” em um editor bloqueia todas as formas de rede ou acesso a arquivos.
Para o importador, use arquivos fictícios e ambiente isolado. Restrinja credenciais e operações de publicação. Instruções no prompt não substituem bloqueios do sistema operacional ou da ferramenta. Comandos de exclusão, migração e envio merecem atenção ao alvo e ao efeito. O trabalho seguro não consiste em perguntar permissão para toda leitura, mas em conhecer o escopo autorizado e impedir efeitos fora dele. Preserve a evidência de execução e reporte limitações reais do ambiente.
Exemplo comentado e limites
FundamentosO teste usa expectativas explícitas e não imprime as linhas. Ele cobre três requisitos locais, mas não comprova autorização por tenant, duplicatas ou processamento de arquivos. Essa lista de lacunas orienta o próximo conjunto de casos e o review.
function validar(linha) {
return typeof linha.id === "string" && linha.id.length > 0 &&
Number.isFinite(linha.valor) && linha.valor >= 0;
}
const casos = [
[{id:"p1",valor:10},true],
[{id:"p2",valor:-1},false],
[{valor:10},false]
];
for (const [entrada,esperado] of casos) {
if (validar(entrada)!==esperado) throw new Error("Contrato violado");
}
console.log({etapa:"validacao",casos:casos.length,status:"aprovado"});O log final informa etapa, quantidade e status sem incluir conteúdo pessoal. Em uma aplicação real, acrescente loteId e correlação, preservando uma política de retenção. Não use os exemplos de dados fictícios como justificativa para registrar conteúdo integral em produção.
Exercício aplicado
Um importador aceita valores negativos e grava linhas integrais em logs. Construa testes e revisão que detectem ambas as falhas.
- Escreva entradas e expectativas independentes da implementação.
- Execute e confirme que regressões são detectadas.
- Revise dados emitidos e origem do escopo autorizado.
- Integre tarefas independentes e relate verificações e lacunas.
Abrir resolução comentada
A solução adiciona validação de valor e identificador, testes que falham antes da correção e revisão do logger. O contexto autorizado fornece o tenant; o arquivo não decide a autoridade. Uma etapa E2E pode verificar que rejeições aparecem para o usuário sem expor registros de outras contas.
Para paralelizar, separe review do logger, testes do validador e inspeção da interface. Consolide as descobertas antes de editar fronteiras compartilhadas. A conclusão inclui comandos executados e limitações, não apenas a opinião do assistente sobre segurança.
A entrega mostra pelo menos uma falha detectável antes da correção e a política que impede exposição desnecessária. O plano de autorização deixa claro que a função validar sozinha não protege um sistema multiusuário.
A solução executa oráculos explícitos, provoca a regressão removendo a condição de valor e comprova que ela é detectada. O importador usa contexto de tenant e rejeita escopo diferente. O logger grava contagens e códigos, e o assert confirma ausência do segredo fictício. O relatório integra os componentes testados, documenta que não houve subagentes e registra persistência e E2E como lacunas, sem inventar revisões ou execução externa.
import assert from "node:assert/strict";
const ctx={tenant:"A"};const logs=[];
function validar(linha){return typeof linha.id==="string"&&linha.id.length>0&&
Number.isFinite(linha.valor)&&linha.valor>=0;}
const casos=[{entrada:{id:"p1",valor:10},esperado:true},
{entrada:{id:"p2",valor:-1},esperado:false},
{entrada:{valor:10},esperado:false},{entrada:{id:"",valor:3},esperado:false},
{entrada:{id:"p3",valor:Infinity},esperado:false}];
function testar(funcao){return casos.every(c=>funcao(c.entrada)===c.esperado);}
assert.ok(testar(validar));
const mutante=linha=>typeof linha.id==="string"&&linha.id.length>0&&Number.isFinite(linha.valor);
assert.equal(testar(mutante),false);
function importar(linhas,contexto){
const aceitas=[],rejeitadas=[];
linhas.forEach((linha,i)=>{
if(linha.tenant!==contexto.tenant)rejeitadas.push({linha:i+1,codigo:"ESCOPO_INVALIDO"});
else if(!validar(linha))rejeitadas.push({linha:i+1,codigo:"DADOS_INVALIDOS"});
else aceitas.push({id:linha.id,valor:linha.valor,tenant:contexto.tenant});
});
logs.push({loteId:"lote-fixture",etapa:"validacao",aceitas:aceitas.length,rejeitadas:rejeitadas.length});
return {aceitas,rejeitadas};
}
const resultado=importar([{tenant:"A",id:"p1",valor:10,segredo:"DADO_SENSIVEL_FICTICIO"},
{tenant:"A",id:"p2",valor:-1},{tenant:"B",id:"p3",valor:10}],ctx);
assert.equal(resultado.aceitas.length,1);assert.equal(resultado.rejeitadas.length,2);
assert.equal(JSON.stringify(logs).includes("DADO_SENSIVEL_FICTICIO"),false);
assert.ok(resultado.aceitas.every(x=>x.tenant==="A"));
const revisao={achados:[{cenario:"Valor negativo",evidencia:"mutante reprovado",resolucao:"valor >= 0"},
{cenario:"Outro tenant",evidencia:"rejeição ESCOPO_INVALIDO",resolucao:"contexto autenticado"}],
integracao:{validacao:"testada",logger:"testado",escopo:"testado"},
agentesParalelos:"não utilizados; integrar relatórios reais quando houver delegação",
lacunas:["persistência e idempotência de lote","E2E em interface real"]};
assert.ok(Object.values(revisao.integracao).every(x=>x==="testado"||x==="testada"));
console.log({status:"aprovado",resultado,logs,revisao});Como conferir seu resultado
- Expectativas derivam do contrato.
- Logs não contêm dados sensíveis fictícios.
- Resultados de subagentes foram integrados e verificados.
Aplique em um problema novo
Primeiro resolva sem consultar a resposta. Explique suas decisões e guarde a evidência. A conclusão de leitura é independente desta autoavaliação.
Confira seus pré-requisitos
- Definir oráculo pelo requisito.
- Minimizar dados em logs.
Importador aceita valor negativo, loga token e recebe tenant livre. Separe defeitos e trabalho paralelo.
Conferir raciocínio e critérios de domínio
O validador aceita um comportamento proibido: o teste deve esperar rejeição do valor negativo e falhar na implementação atual.
O token é dado sensível desnecessário no logger; a saída correta conserva correlação/status e remove o segredo.
O tenant do arquivo não define autoridade. Investigação de validação, inspeção do logger e teste da UI podem ser tarefas independentes; a integração reúne evidências das três fronteiras.
Evidências para autoavaliação ou revisão por pares
- Validação: O validador aceita um comportamento proibido: o teste deve esperar rejeição do valor negativo e falhar na implementação atual.
- Logs: O token é dado sensível desnecessário no logger; a saída correta conserva correlação/status e remove o segredo.
- Autoridade: O tenant do arquivo não define autoridade. Investigação de validação, inspeção do logger e teste da UI podem ser tarefas independentes; a integração reúne evidências das três fronteiras.
Um erro frequente
Sem alertas significa sem vulnerabilidade.
Ausência de alerta é evidência limitada.
Teste sua compreensão
Responda com suas palavras antes de abrir o comentário. Saber explicar uma decisão é parte do domínio.
1. Teste que copia a implementação oferece bom oráculo?
Não.
A expectativa precisa vir do contrato; duplicar a lógica pode duplicar o erro.
2. Ausência de log prova ausência de evento?
3. Subagentes eliminam a integração?
Seu progresso fica salvo neste navegador. Concluir a leitura não substitui demonstrar o domínio nos exercícios.
Referências e aprofundamento
Documentação oficial e trabalhos originais. As referências registram o escopo e as limitações para você conferir o que sustentam.
- Common workflows
Anthropic • consulta: 2026-10-06
AutomaçãoExploração de codebase, debugging, refatoração, testes, review e análise assistida.
Limites: Resultados do agente devem ser verificados com testes, análise estática e review humano apropriado.
- Playwright Best Practices
Microsoft / Playwright • consulta: 2026-10-06
FundamentosTestes E2E de comportamento visível, isolamento, locators e assertions confiáveis.
Limites: Documentação dinâmica; fixar a versão usada no laboratório e conferir compatibilidade antes de executar.
- GitHub Copilot on GitHub.com
GitHub • consulta: 2026-10-06
FundamentosSuperfície Copilot, agente de coding e fluxo de review no GitHub.
Limites: Disponibilidade e limites dependem de plano e organização; verificar antes do laboratório.
- Safety in building agents
OpenAI • consulta: 2026-10-06
OpenAIAgentesPrompt injection, vazamento de dados, entradas não confiáveis e aprovação de tools.
Limites: Prompt de segurança não substitui permissões da aplicação; guia pode mostrar ferramentas legadas, aplicar os princípios em stack atual.
- Create custom subagents
Anthropic • consulta: 2026-10-06
AgentesSubagentes especialistas, isolamento de contexto e tarefas delegadas.
Limites: Paralelismo não elimina conflitos de escrita; definir propriedade de arquivos e integrar resultados.
- OpenCode Agents
OpenCode • consulta: 2026-10-06
AgentesAgentes primários, subagentes, configuração, tools e permissões.
Limites: Documentação dinâmica; fixar a versão usada no laboratório e conferir compatibilidade antes de executar.
- Permission profiles
OpenAI • consulta: 2026-10-06
OpenAIPerfis de permissões, acesso a arquivos, rede e execução de comandos.
Limites: Suporte e isolamento variam por SO/cliente; hierarquia de instruções não substitui barreira do sistema operacional.
- Sandbox
OpenAI • consulta: 2026-10-06
OpenAISandbox de comandos, fronteiras de filesystem/rede e diferenças entre clientes.
Limites: Sandbox de processo tem limites por plataforma; conferir configuração ativa e política de aprovação.
- Configure permissions
Anthropic • consulta: 2026-10-06
FundamentosRegras allow/ask/deny, autorização de tools e comportamento de execução.
Limites: Semântica específica Claude Code; não transportar padrões para outro agente sem adaptação.