Durante anos, times Salesforce trabalhando em orgs grandes e altamente interdependentes aceitaram uma realidade dolorosa: pipelines longos, execução massiva de testes e convenções de nomenclatura usadas como proxy para análise de impacto.
O Spring '26 muda esse modelo de forma concreta.
O problema: testes que não precisam rodar
Em orgs complexas, o ciclo de deploy funciona assim: você altera um trigger em Apex, o pipeline executa todos os testes da org para garantir cobertura, e você espera 40 minutos para descobrir que 35 minutos eram de testes que não têm nada a ver com o que você mudou.
A tentativa tradicional de resolver isso é nomenclatura rígida — chamar os testes de AccountTriggerHandlerTest para que o sistema "saiba" o que rodar. Mas em orgs reais, com anos de contribuições de times diferentes, essa disciplina raramente sobrevive.
A solução do Spring '26: RunRelevantTests (Beta)
Com o novo RunRelevantTests, a Salesforce move a execução de testes de uma abordagem baseada em convenções de nome para inteligência de dependência no nível de plataforma.
O que isso significa na prática:
- A plataforma avalia o que foi alterado
- Entende o que é impactado por essa mudança
- Executa somente os testes que importam
Isso é especialmente transformador para:
- Orgs com código Apex fortemente acoplado
- Times sem convenções rígidas de nomenclatura
- Pipelines de CI/CD travados por milhares de testes não relevantes
- Grandes programas onde o tempo de execução de testes é o principal gargalo de deploy
Os novos decorators: intenção do desenvolvedor sobre inteligência da plataforma
O que torna essa release estrategicamente interessante é que a automação não substitui a intenção do desenvolvedor — ela amplifica.
Depois que a Salesforce seleciona os testes relevantes, você pode estender a cobertura de forma intencional com dois novos decorators:
@IsTest(testFor=...)
Vincula um teste explicitamente a uma classe ou trigger:
@IsTest(testFor=AccountTriggerHandler.class)
private class AccountTriggerHandlerTest {
// ...
}
@IsTest(critical=true)
Garante que um teste sempre rode, independente do que foi alterado. Use para lógica de negócio crítica:
@IsTest(critical=true)
private class PaymentProcessorTest {
// Sempre roda — zero exceção
}
O resultado é um modelo em camadas:
✔ Relevância guiada pela plataforma
✔ Garantias definidas pelo desenvolvedor
✔ Pipelines mais rápidos sem comprometer confiança
O que isso não é
Antes de planejar adoção, algumas ressalvas importantes:
- Ainda é Beta — pode não estar disponível em toda org. Teste em sandbox antes de qualquer plano de produção.
- Não resolve dados de teste ruins — se seus testes têm dependências implícitas não mapeadas, o comportamento pode ser imprevisível.
- Não elimina a necessidade de boas práticas —
@IsTest(critical=true)pressupõe que você sabe o que é crítico. Esse conhecimento precisa existir no time.
Impacto real para arquitetos e tech leads
Para quem gerencia orgs enterprise, essa mudança redefine o que "deploy seguro" significa. Não é mais "rodei todos os testes" — é "rodei os testes certos, com as garantias certas, no menor tempo possível".
O direcionamento da Salesforce está claro: de run everything para run what matters — and only what matters.
Você está testando o RunRelevantTests em Beta? Me conta nos comentários ou no LinkedIn como está sendo a experiência.
