AI coding: tests/review/segurança
Você construirá um conjunto de testes e um review dirigido para um importador fictício. A implementação curta permite observar validação e conteúdo de logs sem depender de serviços externos. Depois você escreverá o plano de integração com autorização e interface.
Use um diretório de prática com dados fictícios. Inspecione qualquer script antes de executá-lo por um agente. A tarefa autoriza validar e testar o exemplo, e o relatório deve distinguir esse escopo de uma avaliação completa de segurança.
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: Leitura: AI coding: tests/review/segurança
Definir os oráculos
FundamentosListe comportamentos antes de escrever o teste: identificador obrigatório, valor finito e não negativo, rejeição sem exposição de conteúdo e escopo autorizado. Para cada comportamento, associe uma entrada que separa correto de incorreto. Um número negativo é mais útil que repetir vários números positivos. O campo tenantId exige um teste de contexto, pois não pertence à função local mostrada. Mantenha essa lacuna visível. Peça ao assistente casos adicionais com a razão de cada um, depois descarte aqueles que só espelham detalhes internos sem observar requisito relevante.
Executar e provocar regressão
FundamentosRode o programa e confirme aprovação. Remova temporariamente a verificação de valor não negativo; o caso correspondente precisa falhar. Essa experiência verifica o poder do teste. Restaure a condição e acrescente NaN, Infinity e identificador vazio conforme o contrato. Preserve saída e versão do arquivo. Se o teste só lê console.log, confirme que erros provocam falha no processo e não são ignorados. O executor de CI deve conseguir distinguir sucesso de texto que apenas diz “aprovado”.
Revisar logs e autorização
FundamentosProcure cada ponto de log no fluxo e classifique quais campos são necessários para diagnóstico. Substitua conteúdo integral por identificadores e contagens onde bastarem. Escreva um caso que introduza um campo sensível fictício e confirme que ele não aparece no log. Para tenant, desenhe a origem do contexto confiável e o ponto de filtro. Um identificador fornecido no arquivo não pode ampliar autoridade. O review deve citar o caminho de exploração possível e a intervenção que o bloqueia, evitando afirmações genéricas de segurança.
Coordenar trabalho e concluir
FundamentosSe usar agentes paralelos, atribua investigação do logger e casos de validação a tarefas independentes, com arquivos delimitados. Receba relatórios com evidência e revise a integração. Não aceite dois relatórios aprovados como prova de que o conjunto funciona junto. Execute as verificações pertinentes após combinar mudanças. Documente também o que não foi avaliado: arquivos grandes, integração com banco e fluxo E2E. O artefato final deve mostrar testes úteis, achados concretos de review e capacidades do terminal realmente usadas.
Caso adicional para diagnóstico e decisão
FundamentosConsidere agora um arquivo de lote com dez mil linhas e uma falha na metade. Escreva antes de implementar se as linhas anteriores ficam aceitas, se todo o lote volta atrás e como o operador descobre o resultado. Essa política altera testes, logs e recuperação. Um assistente que acrescenta retry sem identificar intenção pode duplicar linhas já aceitas. Crie uma simulação curta com três linhas, erro na segunda e repetição do lote. Verifique o número de efeitos, não apenas a mensagem final. Depois acrescente um campo sensível fictício e capture os logs: o campo não deve aparecer, enquanto loteId e código de erro permitem investigar. A rubrica adicional exige política de atomicidade explícita, repetição coerente e diagnóstico sem exposição indevida. Compare revisão por subagente com revisão sequencial do mesmo fluxo. Se validação e persistência compartilham invariantes, a divisão exige contrato claro e integração final. O retorno de cada agente precisa informar evidência e limite, pois três revisões superficiais não equivalem a uma análise completa. Esse caso amplia o laboratório sem transformar uma validação local em garantia de segurança de importação real.
Execução, inspeção e diagnóstico
FundamentosExecute o conjunto nominal e as regressões deliberadas. Registre os casos que detectam cada falha. Acrescente um log estruturado de erro com código e loteId, sem a linha completa. Verifique visualmente ou por captura local que o conteúdo sensível fictício não foi emitido.
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"});Se uma vulnerabilidade foi apontada sem entrada e efeito, peça uma hipótese concreta. Se o teste não falha após remover a validação, corrija seu oráculo. Se agentes editam a mesma função, interrompa a sobreposição e integre sequencialmente. Diagnóstico bom transforma uma observação em uma próxima verificação.
Exercício aplicado
Entregue testes de validação, review de logs e plano de autorização por escopo.
- 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.
Teste valor 0/-5/id ausente, marcador secreto e tenant de outra conta no arquivo.
Conferir raciocínio e critérios de domínio
Com id presente, valor zero é aceito. Valor −5 ou id ausente são rejeitados antes da importação; aceitar −5 seria a falha reproduzida.
O marcador secreto não aparece na saída sanitizada. Correlação e código de erro podem permanecer porque não exigem o token.
O tenant do arquivo não concede acesso à outra conta. O resultado esperado é zero leitura/escrita fora do escopo; testes de validador e logger não comprovam a integração de autorização por si.
Evidências para autoavaliação ou revisão por pares
- Validação: Com id presente, valor zero é aceito. Valor −5 ou id ausente são rejeitados antes da importação; aceitar −5 seria a falha reproduzida.
- Logs: O marcador secreto não aparece na saída sanitizada. Correlação e código de erro podem permanecer porque não exigem o token.
- Autorização: O tenant do arquivo não concede acesso à outra conta. O resultado esperado é zero leitura/escrita fora do escopo; testes de validador e logger não comprovam a integração de autorização por si.
Um erro frequente
Validador unitário protege toda conta.
Autorização exige verificar a fronteira que usa identidade confiável.
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.