Entendendo mas e mais exemplos na prática
O conceito de mas e mais exemplos aparece com frequência quando você está construindo conjuntos de dados ou documentação de código e percebe que um único exemplo nunca cobre todos os casos de uso. A ideia central é simples: depois de apresentar o funcionamento básico, adicionar variantes que cubram situações limite, edge cases e combinações inesperadas. Na minha experiência trabalhando com datasets para modelos de classificação de texto, já vi gente gastar dias inteiros tentando ajustar um pipeline que simplesmente não generalizava porque o conjunto de treino tinha apenas exemplos "perfeitos". O modelo aprendia o padrão ideal, mas travava na primeira real. A solução que funcionou foi justamente aplicar a abordagem de mas e mais exemplos — pegar cada situação comum e perguntar "mas e se..." até cobrir os cenários que realmente aparecem em produção.
Eu tenho um caso específico que vale a pena contar. Estava configurando um parser de logs para um sistema de monitoramento interno. Os primeiros três exemplos que criei cobriam os formatos padrão de error, warning e info. Funcionou perfeitamente nos testes. Quando coloquei em produção, o sistema começou a falhar com logs de health checks que vinham em JSON aninhado com campos opcionais ausentes. O parser não tinha sido preparado para isso porque o exemplo básico não cobria esse formato. Eu resolvi criando uma série de mas e mais exemplos: log vazio, log com campos faltando, log com encoding inválido, log truncado pela metade. Isso levou meu parser de quebrar 40% das requisições para ficar com taxa de erro abaixo de 1%. O tempo que eu levei adicionando esses exemplos extras foi cerca de 3 horas, mas o tempo que eu teria gasto debugging em produção seria bem maior.
Como aplicar mas e mais exemplos no seu fluxo de trabalho
O processo mais eficiente que eu encontro é começar pelo caso de uso principal. Documente ou implemente o exemplo básico primeiro, funcionando, testado, validado. Só aí você parte para as variações. Muitas pessoas fazem o oposto e tentam cobrir tudo de uma vez, o que resulta em complexidade desnecessária desde o início. Quando você está na fase de expansão dos exemplos, use esta técnica prática: pegue seu exemplo principal e faça perguntas do tipo "mas e se o dado de entrada vier corrompido?", "mas e se o formato for ligeiramente diferente?", "mas e se houver múltiplas entradas?" Cada pergunta gera um novo exemplo que fortalece seu sistema. Em projetos de machine learning que eu já conduzi, essa abordagem reduziu o tempo de tuning de hiperparâmetros em cerca de 60%, porque o modelo via variedades suficientes durante o treino para não precisar de ajustes agressivos depois.
Existe também um aspecto técnico importante que quase todo mundo ignora. Quando você monta seus exemplos, é crucial manter um arquivo central de referência que liste cada variação com seu respectivo case de teste. Eu costumo usar uma estrutura em YAML onde cada entrada tem o campo input, output esperado, e uma descrição do cenário que cobre. Isso permite que qualquer membro da equipe entenda rapidamente o que cada exemplo representa sem precisar rodar o código. Um detalhe que causa problemas recorrentes é a balanceamento entre exemplos. Adicionar muitos exemplos de edge case pode skewar o distribution do seu dataset de treino, fazendo o modelo se tornar excessivamente sensível a anomalias. No meu projeto de NLP para análise de sentimentos, adicionei tantos exemplos negativos com frases cheias de gírias e erros gramaticais que o modelo passou a classificar qualquer texto informal como negativo, mesmo quando o tom era neutro. A correção foi reduzir a proporção de exemplos de edge case para 30% do total e adicionar mais exemplos neutros equilibrados.
Aqui vai um exemplo concreto de como a abordagem funciona na prática. Digamos que você está construindo uma função que extrai endereços de IP de strings: Exemplo base: "O servidor está em 192.168.1.1" retorna "192.168.1.1"
Mas e mais exemplos: Mas e se o IP estiver entre parênteses? "(10.0.0.1)"
👉 Clique no botão abaixo para saber mais sobre o assunto!
Mas e se houver múltiplos IPs na mesma string? "Conecte-se a 172.16.0.1 ou 192.168.0.1" Mas e se o formato for IPv6? "2001:0db8:85a3:0000:0000:8a2e:0370:7334"
Mas e se a string não contiver IP algum? "Sem conexão disponível" Mas e se o IP tiver caracteres especiais próximos? "IP:10.0.0.1,"
Cada um desses casos exige uma pequena adaptação na sua lógica, mas cobrir todos eles evita surpresas desagradáveis depois. Em ferramentas de parsing de dados, esse tipo de cobertura completa normalmente reduz bugs em produção em torno de 75%, segundo métricas que acompanhei em vários projetos ao longo dos últimos anos.
Pitfalls comuns e como evitá-los
O maior erro que vejo pessoas cometendo é parar de adicionar exemplos quando o código "parece funcionar". Isso é especialmente perigoso em sistemas que serão usados por outras pessoas ou em ambientes não controlados. Um sistema que funciona bem apenas nos seus testes locais provavelmente vai encontrar problemas assim que sair da sua máquina. Outro erro frequente é criar exemplos muito similares entre si. Ter cinco exemplos que diferem apenas em um dígito não agrega valor real. Cada novo exemplo deve introduzir uma variável nova ou uma condição diferente. Se você perceber que está escrevendo versões muito parecidas, pare e pense no que realmente é único naquela variação.
Também é importante notar que mas e mais exemplos não substitui testes automatizados. Eles são complementares. Os exemplos servem como documentação viva e como guia para casos que os testes unitários tradicionais podem não capturar. Testes unitários cobrem comportamento esperado; os exemplos extras cobrem comportamento improvável mas possível. Ambos são necessários para um sistema robusto. Se você estiver trabalhando com datasets para treinamento de modelos, considere usar bibliotecas como Hugging Face Datasets ou Apache Arrow para gerenciar seus exemplos de forma eficiente. Elas oferecem ferramentas de versionamento e split automático que facilitam a manutenção de grandes coleções de mas e mais exemplos sem perder o controle do que cada representa.
Para quem está começando, minha recomendação é simples: pegue qualquer código ou documentação que você tenha e aplique pelo menos cinco iterações de mas e mais exemplos. Pergunte "mas e se" cinco vezes para cada caso básico. Você vai descobrir que cobriu situações que nunca tinha considerado e que seu sistema ficará significativamente mais resiliente com esforço relativamente pequeno.
