@isTest & test methods

• Marks class/method as test code — doesn't count against code size, can't be called by users, not exposed via API.
• A test method takes no parameters, returns void, is marked @isTest.

@isTest
private class AccountTest {
    @isTest
    static void testInsertAccount() {
        // ...
    }
}

Test isolation & SeeAllData

• Tests must never depend on existing org data — always create your own.
• Default @isTest = SeeAllData=false (good): isolated, repeatable, portable, deploy-safe.
• SeeAllData=true exposes real records — avoid it. Rare exceptions: standard Price Book, some setup/legacy data.

Assertions

• Prefer System.assertEquals(expected, actual) — best error messages, Salesforce-recommended.
• Also: assert(), assertNotEquals(), assertNotNull().

System.assertEquals(1, accounts.size());
System.assertNotEquals(null, acc.Id);
System.assertNotNull(contact);

Positive · Negative · Bulk

• Positive: valid input → expect success.
• Negative: invalid input → expect exception.
• Bulk (200): triggers always receive lists — never test just one record. Exam favourite.

// Negative test
try {
    insert new Account();      // missing required Name
    System.assert(false);
} catch (Exception e) {
    System.assert(true);
}

Future methods

• Must be static, void, @future. Cannot return a value or be called from another future method.
• Parameters: primitives / collections of primitives / IDs only — no sObjects.
• Callouts need @future(callout=true).

@future(callout=true)
public static void sendEmail(Id accountId) { }

Queueable Preferred

• Handles complex objects, supports chaining, returns a Job ID, better monitoring.
• Newer than Future and the recommended choice for new development.

System.enqueueJob(new MyQueueable());

Batch Apex

• Database.Batchable<SObject> → start(), execute(), finish().
• Default scope 200, max 2000. execute() runs once per batch scope (1000 records ÷ 200 = 5 executes).

Test.startTest();
Database.executeBatch(new AccountBatch(), 200);
Test.stopTest();

Scheduled Apex

• Implements Schedulable with execute(); scheduled via System.schedule().
• Cron: Seconds Minutes Hours Day Month Day-of-week [Year].

Test.startTest();
System.schedule('Job', '0 0 12 * * ?', new MyScheduler());
Test.stopTest();       // runs at stopTest; '0 0 12 * * ?' = daily 12 PM

System.runAs()

• Runs a block as another user — tests only. Used to test sharing/visibility and to avoid Mixed DML.
• Changes: current user, sharing rules, role hierarchy, ownership, record access.
• Does NOT change: governor limits, license limits, CRUD/FLS or profile permissions automatically.

System.runAs(user2) {
    insert account;   // runs as user2
}

Test utilities to memorize

• Test.startTest() — reset limits
• Test.stopTest() — run async
• Test.setMock() — register callout mock
• Test.loadData(Account.class,'CSV') — load CSV static resource
• Test.isRunningTest() — true in test context (use sparingly; prefer DI)
• Test.getStandardPricebookId() — only way to get the Standard Price Book

Debug logs & Trace Flags

• Logs record triggers, SOQL, DML, flows, validation, CPU/heap, exceptions.
• Detailed logs need an active Trace Flag (User + Duration + Log Levels). Without it you may not get detailed logs. Exam favourite.

Log levels (low → high verbosity)

Log categories

• Apex Code — method calls, variables, System.debug()
• Database — SOQL, SOSL, DML
• Workflow — workflow rules, Flow, Process Builder
• Validation — validation rules
• Callout — HTTP requests/responses
• Also: Apex Profiling, System, Visualforce, NBA, Lightning

System.debug()

• Default level is DEBUG; logs only — never changes execution.

System.debug('Hello');
System.debug(LoggingLevel.ERROR, 'Failure');

Developer Console

• Execute Anonymous — run Apex immediately (not saved, no coverage).
• Query Editor — quick SOQL/SOSL.
• Log Inspector — timeline, SOQL/DML, call stack, execution units, heap, limits.
• Checkpoints — read-only variable inspection at a line (don't modify).
• Heap Dump, Test execution.

try / catch / finally

• finally always runs, even after an exception.

try {
    insert account;
} catch (DmlException e) {
    System.debug(e.getMessage());
} finally {
    System.debug('Done');
}

Common runtime errors

• Too many SOQL / DML; CPU timeout; heap exceeded
• Mixed DML — setup-object DML + non-setup DML in one transaction (e.g. insert User + insert Account)
• Duplicate value / unique field / duplicate rule
• FIELD_CUSTOM_VALIDATION_EXCEPTION, NullPointer, QueryException

Change Sets

• Built-in; works only between related orgs (e.g. Sandbox → Production). Not between unrelated orgs.
• Outbound = sending org (sandbox); Inbound = receiving org (production).
• Steps: create → add components → upload → deploy. Always include dependencies (missing field → deploy fails).

Validation & Quick Deploy Favourite

• Validation checks a deployment & runs tests without committing — safe, finds errors, no prod changes.
• Quick Deploy is available only after a successful validation — skips re-running tests, faster to prod.

Salesforce DX & Scratch Orgs

• Modern, source-driven: CLI + Git + Scratch Orgs + Packages + CI/CD.
• Scratch Org = temporary, disposable, created from a config file (source). Sandbox = long-lived, persistent, has org data.

Metadata API & ANT

• Metadata API deploys/retrieves metadata — used by VS Code, CLI, ANT, CI/CD.
• ANT Migration Tool = older, uses Metadata API. Know purpose.
• Deletions via destructiveChanges.xml.

Deployment order & atomicity

• Order by dependency: Objects → Fields → Validation Rules → Apex → Lightning → Permissions → Profiles.
• Deployment is atomic: failure rolls back everything. No partial deploys.

Profiles vs Permission Sets & hardcoding

• Profile = baseline, one per user. Permission Set = additive, many allowed. Salesforce recommends Permission Sets.
• Never hardcode IDs like '001XXX...' — use SOQL, Custom Metadata, Custom Settings, or Named Credentials.

Governor limits

• SOQL sync 100 / async 200 · DML 150
• Future 50 · Queueable 50 · Batch default 200
• Heap 6 MB sync / 12 MB async · CPU 10 s sync / 60 s async

Collections

• List — ordered, duplicates OK
• Set — unordered, unique
• Map — key → value, fast lookup

SOQL vs SOSL

• SOQL — one object (or related), structured, exact fields
• SOSL — many objects, text search, FIND

Trigger context

• Trigger.new — insert/update (not delete)
• Trigger.old — update/delete (not insert)
• Before = modify same record · After = related records / IDs

Access & keywords

• private class · protected subclass · public namespace · global everywhere (managed pkg / web services)
• static shared by all instances · final can't change/override/extend
• this current object · super parent class

Annotations

• @AuraEnabled — expose Apex to LWC/Aura
• @future — async · @InvocableMethod — Flow
• @isTest, @testSetup — testing · @TestVisible — expose private to tests

DML & partial success

• insert list; → all-or-none (whole txn fails)
• Database.insert(list, false) → partial success (exam favourite)
• Methods: insert, update, delete, upsert, merge, undelete

Security

• OWD = baseline · Role hierarchy = vertical · Sharing rules = horizontal · Permission sets = extra
• with sharing = record sharing · WITH USER_MODE = CRUD/FLS
• Sharing ≠ CRUD/FLS

LWC quick hits

• Decorators: @api public · @track reactive (mostly automatic now) · @wire reactive data
• Lifecycle: constructor → connectedCallback → renderedCallback → disconnectedCallback → errorCallback
• Parent→child = property/@api · child→parent = Custom Event
• @wire = auto/cacheable · imperative = manual (button)
• LDS — no Apex, uses UI API, respects security, caches

Relationships & automation

• Lookup = optional · Master-Detail = required + cascade delete + roll-up summary
• Roll-up (COUNT/SUM/MIN/MAX) works only on Master-Detail, not Lookup
• Formula calculates; roll-up aggregates
• Prefer Flow over Apex for simple automation; prefer Queueable for async