O recurso do Spring ’26 que elimina o gargalo mais antigo do desenvolvimento Salesforce
Se você trabalha com Salesforce há algum tempo, já passou por isso. Você muda uma única linha de uma classe Apex, roda o deploy e espera. E espera mais. Porque o Salesforce insiste em executar cada teste da sua org, mesmo aqueles que não têm relação nenhuma com o que você alterou.
Em orgs grandes, com milhares de classes e centenas de testes, esse ciclo de deploy pode levar horas. Literalmente. Eu já vi orgs onde um deploy simples de 15 minutos de código levava 4 horas para passar nos testes. Isso quando não falhava por timeout.
O RunRelevantTests, introduzido no Spring ’26 como beta, muda essa equação. Em vez de rodar tudo, ele executa apenas os testes que realmente importam para o que você está fazendo.
O problema que todo mundo conhece (e ninguém gosta de enfrentar)
O Salesforce sempre exigiu que deploys de código Apex passassem por testes. Faz sentido: você quer garantir que suas mudanças não quebraram nada. O problema é a abordagem de “tudo ou nada”.
Quando você roda sf project deploy start --test-level RunLocalTests, o Salesforce executa todos os testes da org. Isso inclui testes que foram escritos cinco anos atrás por um consultor que saiu da empresa, testes que cobrem funcionalidades que ninguém usa mais, e testes que testam classes que não têm conexão alguma com o seu deploy.
Em orgs de Enterprise com histórico de 10+ anos, não é incomum ter 3.000 ou 4.000 classes Apex. Cada deploy roda centenas de testes. Se cada teste leva em média 30 segundos, estamos falando de horas de espera para uma alteração de uma linha.
O RunSpecifiedTests existia como alternativa, mas exigia que você manualmente listasse quais testes rodar. Isso adicionava trabalho manual, era propenso a erros (você esquece de incluir um teste crítico e o bug vai para produção), e ninguém realmente usava em produção.
Como o RunRelevantTests funciona por dentro
A ideia é simples, mas a execução é sofisticada. Quando você faz um deploy com RunRelevantTests, o Salesforce analisa automaticamente o que está sendo alterado e descobre quais testes são relevantes para essas mudanças.
O mecanismo usa três critérios para determinar quais testes executar:
1. Testes incluídos no payload do deploy. Se você está fazendo deploy de uma classe de teste, ela vai rodar. Isso é óbvio, mas é o primeiro filtro.
2. Descoberta automática via grafos de dependência. Aqui está a mágica. O Salesforce analisa suas classes Apex que estão sendo alteradas e usa grafos de referência e dependência para encontrar testes que exercitam essas classes. Se você mudou AccountService.cls, o Salesforce identifica automaticamente todos os testes que fazem referência a essa classe, direta ou indiretamente.
3. Marcações manuais com anotações. Para os casos onde a análise automática não é suficiente, você pode usar duas anotações especiais.
@IsTest(testFor=…)
Essa anotação permite que você declare explicitamente quais classes e triggers um teste cobre. É útil quando a dependência não é direta, ou quando você quer garantir que determinado teste sempre rode quando certa classe mudar.
@IsTest(testFor='AccountService,AccountTrigger')
private class AccountServiceTest {
@IsTest
static void testAccountCreation() {
Account acc = new Account(Name = 'Test Account');
insert acc;
// O teste valida que AccountService e AccountTrigger
// funcionam corretamente
Account result = [SELECT Id, Name FROM Account WHERE Id = :acc.Id];
System.assertEquals('Test Account', result.Name);
}
}
Nesse exemplo, sempre que AccountService ou AccountTrigger estiverem no payload do deploy, esse teste vai ser executado automaticamente, mesmo que a análise de dependências não consiga detectar a conexão.
@IsTest(critical=true)
Para testes que devem rodar em todo deploy, independente do que está sendo alterado. Pense nisso como um “always run” para cenários onde determinado teste é crítico demais para ser pulado.
@IsTest(critical=true)
private class CriticalBusinessLogicTest {
@IsTest
static void testRevenueCalculation() {
// Este teste SEMPRE deve rodar em qualquer deploy
// porque valida a lógica de cálculo de receita
Decimal revenue = RevenueService.calculateQuarterlyRevenue();
System.assert(revenue >= 0, 'Revenue must be non-negative');
}
}
Essa abordagem híbrida (automática + manual) dá flexibilidade sem sacrificar segurança. Você confia na automação para o grosso do trabalho e usa as anotações para os casos especiais.
Como usar na prática
A implementação é direta. Você tem três caminhos dependendo de como faz deploy:
Via Salesforce CLI
O caminho mais comum para quem usa VS Code ou CI/CD:
sf project deploy start --test-level RunRelevantTests
É literalmente trocar RunLocalTests por RunRelevantTests. Nada mais muda no seu workflow.
Via Metadata API
Para quem usa a API diretamente ou ferramentas customizadas, basta configurar o testLevel no objeto DeployOptions:
// Exemplo via Apex Metadata API
Metadata.DeployOptions options = new Metadata.DeployOptions();
options.testLevel = 'RunRelevantTests';
MetadataService.deploy(zipFile, options);
Ou via REST:
{
"deployOptions": {
"testLevel": "RunRelevantTests"
}
}
Via workbench ou outras ferramentas
Qualquer ferramenta que suporte a Metadata API pode usar o novo test level. Basta configurar RunRelevantTests no campo de test level.
O impacto real nos seus deploys
Os números vão variar de org para org, mas a tendência é clara. Em orgs com muitos testes e deploys frequentes, a redução no tempo de deploy é significativa.
Pense numa org com 2.000 classes Apex e 800 classes de teste. Um deploy que altera 3 classes de serviço normalmente roda todos os 800 testes. Com RunRelevantTests, talvez sejam executados 20 ou 30 testes que realmente se conectam a essas 3 classes. A diferença de tempo pode ser de horas para minutos.
Isso tem um efeito cascata no ciclo de desenvolvimento. Quando o deploy é rápido, os desenvolvedores fazem deploys mais frequentes. Deploys mais frequentes significam integração contínua de verdade, não a versão “fazemos deploy toda sexta-feira com medo”. E isso reduz o risco de cada deploy individual, porque as mudanças são menores e mais fáceis de reverter.
Preparando sua org para o RunRelevantTests
Antes de sair usando, vale investir tempo em preparação. O recurso funciona melhor quando seus testes estão organizados.
Organize seus testes por responsabilidade
Se os seus testes estão bem estruturados, com cada classe de teste cobrindo uma ou duas classes de serviço, a análise automática de dependências vai funcionar bem. Se você tem testes monolíticos que testam tudo ao mesmo tempo, o Salesforce pode acabar incluindo testes desnecessários.
// Bom: teste focado, fácil de detectar dependência
@IsTest
private class AccountServiceTest {
// Testa apenas AccountService
}
// Problemático: teste monolítico
@IsTest
private class AllServicesTest {
// Testa AccountService, ContactService, OpportunityService...
// O Salesforce vai executar esse teste se QUALQUER uma dessas mudar
}
Use testFor em testes com dependências indiretas
Se um teste valida um cenário de integração que passa por múltiplas classes, use testFor para declarar explicitamente as dependências:
@IsTest(testFor='AccountService,ContactService,AccountTrigger')
private class AccountContactIntegrationTest {
// Quando AccountService OU ContactService mudarem,
// esse teste vai rodar
}
Marque testes críticos com critério
Não marque todos os testes como critical=true. O valor do recurso está em pular testes irrelevantes. Reserve o critical para testes que validam regras de negócio fundamentais que todo deploy precisa confirmar.
Adapte seu pipeline de CI/CD
Se você usa GitHub Actions, GitLab CI, Jenkins ou qualquer outra ferramenta, atualize seus scripts de deploy:
# Exemplo para GitHub Actions
- name: Deploy to Sandbox
run: sf project deploy start --test-level RunRelevantTests --target-org sandbox
Considerações importantes
O RunRelevantTests está em beta no Spring ’26. Isso significa algumas coisas.
Primeiro, o comportamento pode mudar entre releases. A Salesforce está refinando o algoritmo de descoberta de dependências com base no feedback da comunidade. Se algo parecer errado, reporte.
Segundo, não confie cegamente na seleção de testes. Em produção, considere rodar RunLocalTests periodicamente (semanalmente ou em releases planejados) para garantir que nada foi perdido. O RunRelevantTests é ideal para o ciclo de desenvolvimento diário, não necessariamente para o deploy final em produção.
Terceiro, o recurso funciona melhor com testes bem organizados. Se seus testes são bagunçados, a análise automática pode não conseguir identificar todas as dependências relevantes. Invista em organizar seus testes antes de confiar plenamente no recurso.
O que vem depois
O RunRelevantTests é parte de uma tendência maior da Salesforce de reduzir a fricção no ciclo de desenvolvimento. Os Apex Cursors, também do Spring ’26, eliminaram o gargallo de processamento em massa. A preview de componentes individuais do LWC no Summer ’26 acelerou o front-end. E o @IntegrationTest do Summer ’26 permite testar integrações reais com Agentforce e Data 360 em scratch orgs.
Juntos, esses recursos estão transformando o desenvolvimento Salesforce de um processo lento e cauteloso em algo mais próximo do que desenvolvedores de outras plataformas consideram normal. Deploy rápido, feedback imediato, iteração contínua.
Se você ainda não experimentou o RunRelevantTests, vale a pena. Comece em um sandbox, compare os tempos de deploy com o que você tinha antes, e ajuste seus testes conforme necessário. O ganho de produtividade compensa o investimento inicial em organização.
Referências: