Salesforce Apex Quality Guardrails

Aplique estas verificações a todas as classes, triggers e arquivos de teste Apex que você escrever ou revisar.

Etapa 1 — Verificação de Segurança de Limites do Governador

Analise estes padrões antes de declarar qualquer arquivo Apex como aceitável:

SOQL e DML em Loops — Falha Automática

// ❌ NEVER — causes LimitException at scale
for (Account a : accounts) {
    List<Contact> contacts = [SELECT Id FROM Contact WHERE AccountId = :a.Id]; // SOQL in loop
    update a; // DML in loop
}

// ✅ ALWAYS — collect, then query/update once
Set<Id> accountIds = new Map<Id, Account>(accounts).keySet();
Map<Id, List<Contact>> contactsByAccount = new Map<Id, List<Contact>>();
for (Contact c : [SELECT Id, AccountId FROM Contact WHERE AccountId IN :accountIds]) {
    if (!contactsByAccount.containsKey(c.AccountId)) {
        contactsByAccount.put(c.AccountId, new List<Contact>());
    }
    contactsByAccount.get(c.AccountId).add(c);
}
update accounts; // DML once, outside the loop

Regra: se você vir [SELECT ou Database.query, insert, update, delete, upsert, merge dentro do corpo de um loop for — pare e refatore antes de prosseguir.

Etapa 2 — Verificação do Modelo de Compartilhamento

Cada classe deve declarar sua intenção de compartilhamento explicitamente. Compartilhamento não declarado herda do chamador — comportamento imprevisível.

Se uma classe não tiver uma dessas três declarações, adicione-a antes de escrever qualquer outra coisa.

Etapa 3 — Aplicação de CRUD / FLS

O código Apex que lê ou escreve registros em nome de um usuário deve verificar o acesso a objetos e campos. A plataforma não aplica FLS ou CRUD automaticamente no Apex.

// Check before querying a field
if (!Schema.sObjectType.Contact.fields.Email.isAccessible()) {
    throw new System.NoAccessException();
}

// Or use WITH USER_MODE in SOQL (API 56.0+)
List<Contact> contacts = [SELECT Id, Email FROM Contact WHERE AccountId = :accId WITH USER_MODE];

// Or use Database.query with AccessLevel
List<Contact> contacts = Database.query('SELECT Id, Email FROM Contact', AccessLevel.USER_MODE);

Regra: qualquer método Apex chamável de um componente de UI, endpoint REST ou @InvocableMethod deve aplicar CRUD/FLS. Métodos de serviço internos chamados apenas de contextos confiáveis podem usar with sharing em vez disso.

Etapa 4 — Prevenção de Injeção de SOQL

// ❌ NEVER — concatenates user input into SOQL string
String soql = 'SELECT Id FROM Account WHERE Name = \'' + userInput + '\'';

// ✅ ALWAYS — bind variable
String soql = [SELECT Id FROM Account WHERE Name = :userInput];

// ✅ For dynamic SOQL with user-controlled field names — validate against a whitelist
Set<String> allowedFields = new Set<String>{'Name', 'Industry', 'AnnualRevenue'};
if (!allowedFields.contains(userInput)) {
    throw new IllegalArgumentException('Field not permitted: ' + userInput);
}

Etapa 5 — Idiomas Modernos do Apex

Prefira recursos atuais da linguagem (API 62.0 / Winter '25+):

Etapa 6 — Checklist de Cobertura de Teste PNB

Cada funcionalidade deve ser testada em todos os três caminhos. A falta de qualquer um deles é uma falha de qualidade:

Caminho Positivo

• Entrada esperada → saída esperada.
• Afirme os valores exatos dos campos, contagens de registros ou valores de retorno — não apenas que nenhuma exceção foi lançada.

Caminho Negativo

• Entrada inválida, valores nulos, coleções vazias e condições de erro.
• Afirme que exceções são lançadas com o tipo e mensagem corretos.
• Afirme que nenhum registro foi mutado quando a operação deveria ter falhado de forma limpa.

Caminho em Massa

• Insira/atualize/exclua 200–251 registros em uma única transação de teste.
• Afirme que todos os registros foram processados corretamente — sem falhas parciais devido a limites do governador.

…