Testes que passam em qualquer org

Reorganizei os testes da automação de Oportunidades para que funcionem em diferentes ambientes Salesforce, e não apenas naquele onde foram escritos. Agora, cada teste prepara os próprios dados, o que reduz a dependência de informações que podem existir em um ambiente e faltar em outro.

Os testes da automação de Oportunidades passavam em um sandbox, um ambiente separado usado para desenvolvimento e validação, mas falhavam durante a validação em uma org limpa. No Salesforce, org é a instância da plataforma que reúne dados e configurações de uma organização. Essa falha impedia a publicação das alterações.

Parte dos testes usava SeeAllData=true, uma opção que permite ao teste consultar registros existentes no ambiente. Alguns buscavam uma Conta pelo nome e, por isso, dependiam de aquele registro já estar lá. Em uma org diferente, esses dados poderiam não existir.

Além disso, havia testes que criavam versões parecidas dos mesmos dados, mas com pequenas diferenças. Quando uma regra obrigatória mudava, era preciso corrigir vários lugares. Uma alteração de validação também podia fazer falhar testes que não tinham relação direta com ela, dificultando entender se havia um defeito na automação ou apenas dados de teste incompletos.

Limitei o trabalho ao conjunto de testes afetado, sem tentar alterar a configuração inteira do ambiente. Criei uma fábrica de dados de teste (Test Data Factory), que é um conjunto de métodos para preparar registros válidos e reutilizáveis. Ela cria Contas, Contatos e Oportunidades com os valores necessários por padrão; cada teste informa somente o que muda para o cenário que quer verificar, como a etapa ou o valor da Oportunidade.

Usei também @TestSetup, um recurso do Apex para preparar os registros que servirão de base aos métodos de teste. Assim, cada teste pode partir de uma estrutura comum e criar apenas os dados específicos de que precisa. Com essa organização, removi a dependência de dados existentes, os identificadores fixos e as buscas de Conta pelo nome.

Também substituí verificações genéricas, como conferir apenas se um resultado não está vazio, por verificações dos valores esperados, da quantidade de registros e das relações entre eles. O par Test.startTest() e Test.stopTest() delimita a parte do teste que está sendo de fato executada, ajudando a isolar a execução e a validar o comportamento relevante.

O objetivo não era apenas fazer a validação atual passar, mas reduzir a fragilidade que poderia causar falhas semelhantes depois. Corrigir cada teste separadamente manteria várias cópias da mesma preparação de dados, que poderiam voltar a divergir.

Com a fábrica, as regras para criar registros válidos ficam reunidas em um lugar. Se uma nova regra obrigatória exigir outro campo, a preparação pode ser ajustada ali, em vez de procurar e corrigir cada teste individualmente.

Se uma nova regra exigir um campo adicional na Oportunidade, a fábrica pode ser atualizada para preencher esse campo nos dados de base. Os testes deixam de depender de uma Conta que alguém cadastrou manualmente em determinado ambiente, pois usam os registros que eles próprios preparam. Isso permite executar a validação tanto no sandbox quanto em uma org sem aqueles dados prévios.

Os testes do conjunto afetado deixam de depender dos dados encontrados em cada ambiente. O escopo da alteração continua restrito a esses testes: a automação em produção mantém o mesmo comportamento, mudando a forma de preparar e verificar os cenários de teste.