Tema: testing
-
Benchmark de uma alteração: warm-up, repetições, variância e o que reportar
Uma comparação de tempos só é um resultado se resistir ao ruído: fixe a carga de trabalho, descarte as execuções de warm-up, intercale muitas repetições de cada variante, escolha a estatística antes de ver os dados e reporte a dispersão e o ambiente junto de cada número. Uma diferença menor que a dispersão entre execuções não é uma descoberta.
-
Refatoração em passos pequenos e verificados
Refatorar muda a estrutura sem alterar o comportamento; fazê-lo em passos minúsculos, com os testes passando entre um passo e outro, e manter commits de refatoração separados dos de mudança de comportamento torna o processo seguro e fácil de revisar.
-
Como escrever um relatório de bug utilizável
Um relatório de bug é utilizável quando uma pessoa de fora consegue reproduzir o erro sem fazer perguntas: título preciso, ambiente com versões, passos numerados para reproduzir, resultado esperado e resultado real separados, a mensagem de erro literal e um exemplo o menor possível. Suposições sobre a causa ficam numa seção própria.
-
Dados de seed e fixtures para bancos de dados locais: pequenos, idempotentes e versionados junto com o esquema
Separe dados de referência (necessários em todo lugar), dados de exemplo (desenvolvimento e demos) e dados de teste (criados pelos próprios testes). Escreva o seed como código idempotente com upserts em chaves naturais, mantenha o conjunto de exemplo pequeno e nomeado, execute-o após as migrations no script de setup e no CI, e nunca popule máquinas de desenvolvimento com dados brutos de produção.
-
Testes baseados em propriedades com entradas geradas
Em vez de exemplos escolhidos à mão, um teste baseado em propriedades declara um invariante e deixa uma biblioteca gerar muitas entradas, reduzindo as falhas a contraexemplos mínimos; o Hypothesis é a implementação de referência para Python.
-
Gerar, criticar, revisar: quando um ciclo de autoverificação compensa
Um ciclo em que o modelo critica e revisa a própria saída melhora os resultados quando a crítica dispõe de um sinal externo (testes, um validador, uma fonte) e de um critério fixo; sem isso, resultados publicados mostram que pode piorar as respostas, e cada rodada acrescenta pelo menos duas chamadas cuja entrada cresce com o rascunho.
-
Como escrever um teste unitário em JUnit 5 e xUnit.net: anotações, ciclo de vida e casos parametrizados lado a lado
O JUnit Jupiter marca testes com @Test, executa @BeforeEach e @AfterEach em torno de cada um, por padrão numa instância nova, e conduz casos baseados em dados com @ParameterizedTest mais uma anotação de fonte. O xUnit.net usa [Fact], o construtor e IDisposable para a preparação por teste numa instância nova, [Theory] com [InlineData] para os casos e fixtures para contexto compartilhado e caro. Escrever testes com a mesma estrutura nos dois mantém alinhadas as convenções de uma equipe poliglota.
-
Como projetar um pipeline de integração contínua
Um pipeline de CI deve ser rápido, testar a si mesmo e ser idêntico para toda mudança: compilar a partir de um checkout limpo, executar linters e testes em etapas, falhar de forma visível e manter o tempo total curto o bastante para que as pessoas esperem pelo resultado.
-
Bancos de dados efêmeros em contêineres para testes de integração
Suba o motor de banco de dados real em um contêiner descartável a cada execução de testes, mantenha os dados em memória, aplique as migrações uma só vez em um banco-modelo e copie-o para cada arquivo de teste. Assim, os testes exercitam o planejador, as constraints e o comportamento de isolamento reais, em vez de um substituto em memória.
-
Use testes baseados em propriedades para parsers
Expresse invariantes do parser sobre entradas geradas e guarde as falhas minimizadas como exemplos de regressão focados.
-
pass^k em tentativas repetidas prevê incidentes de agentes em produção melhor do que pass@k
Hipótese: em agentes usados em tarefas repetitivas, a taxa de sucesso em todas as tentativas (pass^k) num conjunto de avaliação correlaciona-se mais com a taxa de execuções com falha ou escaladas em produção do que a taxa de sucesso em pelo menos uma tentativa (pass@k), porque em produção cada tarefa tem uma só tentativa.
-
Reprodutibilidade de um experimento de machine learning: seeds, ambiente, dados e os limites do determinismo
Para repetir um experimento e obter o mesmo número, é preciso fixar estados aleatórios passados de forma explícita, fixar versões de bibliotecas, identificar o dataset e a divisão dos dados, e ter em mente que kernels de GPU e novas versões de bibliotecas ainda podem alterar os resultados; o protocolo torna as execuções repetíveis onde possível e documenta onde não são.
-
Red teaming de um fluxo de trabalho de agente antes de ele receber permissões reais
Ataque o agente como conteúdo e usuários o atacarão: injeção indireta de prompt por todas as entradas que ele lê, manipulação de argumentos de ferramentas, exfiltração por chamadas de ferramentas e esgotamento de orçamento. Use sondas automatizadas e tentativas manuais, registre o que o agente fez e corrija a fronteira, não apenas o prompt.
-
Dados de teste sem dados pessoais de produção
Forneça dados realistas a desenvolvimento, CI e staging gerando-os: classifique colunas, escreva geradores com seed que passem nos validadores da aplicação, crie volume com generate_series, copie da produção apenas distribuições, marque os registros gerados de forma reconhecível e elimine o atalho de fazer dump da produção.
-
Qual cobertura de testes é suficiente para um serviço pequeno?
Pergunta em aberto: para um serviço com alguns milhares de linhas, um banco de dados e uma API HTTP, que nível de cobertura e que combinação de testes já foram observados mantendo taxas de defeitos aceitáveis sem atrasar as mudanças?
-
Extração estruturada de documentos com JSON Schema, validação e tentativas limitadas
Defina o registro de destino como um JSON Schema com additionalProperties false, peça ao modelo exatamente essa forma, valide cada resposta com um validador de verdade, repita um número limitado de vezes incluindo o erro de validação no prompt e encaminhe a uma pessoa o que ainda falhar, em vez de adivinhar.
-
Revisão de código escrito por um agente de IA
Proposta de protocolo de revisão para alterações geradas: comparar o diff com o pedido, confirmar que cada API e dependência existe, verificar as afirmações sobre testes executando-os e quebrando-os, ler os testes antes da implementação, procurar erros engolidos e registrar o que foi verificado.
-
O ciclo do desenvolvimento orientado a testes (TDD)
Escreva um teste que falha, faça-o passar com a mudança mais simples possível e depois refatore com os testes verdes; o ciclo mantém as decisões de design pequenas e dá a cada linha de código uma razão de existir.
-
Seletores estáveis e espera automática em testes end-to-end de navegador
Duas causas dominam os testes de navegador instáveis: seletores que quebram ou apontam para o elemento errado, e pausas fixas que pressupõem um tempo de resposta. Localize os elementos por papel (role), rótulo ou test id, garanta que cada localizador corresponda a um único elemento e sincronize com asserções que repetem a verificação e com checagens de acionabilidade, não com o tempo.
-
Executando testes de mutação sem se afogar em mutantes sobreviventes
Rode uma ferramenta de mutação em um único módulo, classifique cada mutante sobrevivente como asserção ausente, caso ausente ou mutante equivalente, corrija os dois primeiros, exclua o terceiro e limite o tempo de execução com execuções incrementais ou restritas ao diff; use a pontuação como um ratchet por módulo, e não como meta global.
Legível por máquina: JSON