Apex Test Class Practice Problems

Problem Statement

Create a TestDataFactory class with static methods to generate realistic test data for Account, Contact, and Opportunity records. Support both insert and no-insert modes.

Requirements

• Use a counter so names are unique per test run
• createContact must accept an Account parameter
• createOpportunity must have valid StageName and CloseDate

Problem Statement

Write a complete @isTest class for the AccountRatingTrigger (Problem 1). The test class must follow all Apex testing best practices.

Requirements

• Use @TestSetup to create shared test data
• Positive test: verify Rating = 'Hot' for revenue > 1M
• Negative test: verify Rating = 'Cold' for revenue < 100K
• Bulk test: insert 200 records and assert all are rated
• Use System.assertEquals() for assertions (not just assert)

Problem Statement

Write a test class AccountRatingTriggerTest with at least 3 test methods covering the Account Rating trigger:

• Revenue > 1,000,000 → Rating = Hot
• Revenue 100,000–1,000,000 → Rating = Warm
• Revenue < 100,000 → Rating = Cold

Requirements

• Use @isTest annotation on the class and each method
• Use Test.startTest() / Test.stopTest()
• Use System.assertEquals() for assertions

Problem Statement

Write a test class ContactDuplicateTest that tests the Contact duplicate-prevention trigger:

• Positive test: inserting a contact with a unique email succeeds
• Negative test: inserting a contact with a duplicate email throws a DmlException

Requirements

• Use try/catch with DmlException in the negative test
• Assert the exception message contains "Email"
• Achieve 100% code coverage of the trigger

Problem Statement

Write a test class OpportunityHelperTest that achieves 100% coverage of OpportunityHelper.isWon() and isLost().

Include test methods for:

• "Closed Won" → isWon = true
• "Closed Lost" → isLost = true
• Any other stage → both return false
• Null input → returns false (no NPE)

Problem Statement

Write a test class BulkTriggerTest that validates that a trigger on Account handles 200 records in a single DML without hitting governor limits.

Requirements:

• Insert 200 Account records in a single insert call
• Assert all 200 were created (query count)
• Assert Limits.getQueries() ≤ 5 (low SOQL usage)
• Assert Limits.getDmlStatements() ≤ 3

Problem Statement

Write a test class AccountServiceTest for AccountService:

• Set up test data using @testSetup
• Test getHotAccounts() returns only accounts with Rating = 'Hot'
• Test deactivateSmallAccounts() updates the right records

Problem Statement

Write a test class HttpCalloutServiceTest that mocks an HTTP callout using HttpCalloutMock.

Steps:

1. Create an inner class implementing HttpCalloutMock
2. Set the mock with Test.setMock()
3. Call HttpCalloutService.callWithRetry() and assert the response

Problem Statement

Write a test class DeactivateOldContactsBatchTest:

• Create 5 Contacts with LastActivityDate 400 days ago
• Execute the batch using Database.executeBatch()
• Assert all 5 have Active__c = false after batch runs

Problem Statement

A trigger + handler already exist that set Account.Rating based on AnnualRevenue (Hot > 1M, Warm 100K–1M, Cold < 100K). Your task is to write a complete test class.

Required Test Methods

• TC01 — Revenue > 1M → Rating = 'Hot'
• TC02 — Revenue 500K → Rating = 'Warm'
• TC03 — Revenue 50K → Rating = 'Cold'
• TC04 — Null Revenue → no exception (graceful)
• TC05 — Bulk insert 200 records → no governor errors
• TC06 — Update Revenue 50K → 2M → Rating changes to Hot

Best Practices

• @isTest on every test method.
• Test.startTest() / Test.stopTest() wrapping DML.
• Re-query the record after DML before asserting.
• System.assertEquals for all assertions.

Problem Statement

A trigger + handler prevent two Contacts sharing the same Email. Write a comprehensive test class covering all scenarios below.

Required Scenarios

• Positive — Unique email inserts successfully.
• Negative — Duplicate email throws DmlException with "already exists".
• Case-insensitive — UPPER@test.com blocks upper@test.com.
• Self-update — Updating own record without changing email passes.
• Bulk unique — 50 contacts with unique emails all insert.
• Bulk duplicate — 49 unique + 1 duplicate → only duplicate blocked.

Problem Statement

A handler exists that on before update of a Case:

• Status → 'Escalated' (new): sets Priority = 'High' and Escalation_Reason__c = 'SLA Breach — auto-escalated'.
• Status was already 'Escalated': calls addError('Case is already escalated.').

Write a full test class covering all six scenarios:

• Valid escalation → Priority = High, reason contains "SLA".
• Double escalation → DmlException with "already escalated".
• Non-escalated status change → Priority unchanged.
• Bulk 50 valid escalations → all Priority = High.
• Bulk mixed (25 new + 25 already escalated) → 25 errors using Database.update(false).
• Escalation_Reason__c content assertion → contains "SLA".

Problem Statement

Write a complete @isTest class for NightlyStaleLeadLauncher (from the previous problem — a Schedulable that launches FlagStaleLeadsBatch) that verifies both:

1. Scheduling it actually registers a CronTrigger with the right cron expression.
2. Its execute() method genuinely launches the batch and the batch's logic runs correctly.

Requirements

• testSchedulingRegistersACronTrigger: call System.schedule(...) inside Test.startTest()/Test.stopTest(), then query CronTrigger by the returned job Id and assert its CronExpression and NextFireTime.
• testExecuteLaunchesTheBatch: insert a stale Lead, call new NightlyStaleLeadLauncher().execute(null) directly inside Test.startTest()/Test.stopTest(), then re-query the Lead and assert Status = 'Stale'.

Best Practices

• Scheduled Apex genuinely fires within Test.startTest()/Test.stopTest() in Salesforce's test framework — but asserting on the CronTrigger record (rather than assuming side effects happened) is the more precise, deterministic way to verify the scheduling itself worked.
• Calling execute(null) directly is the standard way to test a Schedulable's actual business logic — you don't need a real cron fire to exercise what execute() does.
• Covering both angles (the scheduling mechanics and the executed logic) is what makes this test class complete, rather than just asserting one or the other.

Problem Statement

Write a test class OpportunityForecastTriggerTest with test methods covering the Opportunity forecast-category trigger across multiple distinct scenarios in one bulk operation: a high-probability deal, a mid-probability deal, and a zero-amount deal, all inserted together.

Requirements

• Insert all three Opportunity variants in a single bulk DML inside Test.startTest()/Test.stopTest().
• Re-query all three afterward and assert each one's resulting Forecast_Category_Custom__c independently.

Problem Statement

Write a test class PartialInsertHandlerTest that verifies code using Database.insert(records, false) (allow-partial-success mode) correctly separates successful records from failed ones by inspecting the returned List<Database.SaveResult>.

Requirements

• Insert a mix of records expected to succeed and one expected to fail (e.g. a required field left blank).
• Iterate the SaveResult list, checking isSuccess() per record and asserting the success/failure count matches expectations.

Problem Statement

Write a test class AccountLifecycleTest that covers a two-step lifecycle: insert an Account in one transaction, then update it in a second, separately-timed transaction, asserting the state after each step.

Requirements

• The insert and the update must be genuinely separate DML statements, not combined into one.
• Assert the post-insert state before performing the update, then assert again after it.

Problem Statement

Write a test class DiscountConfigLookupTest that verifies a service method gracefully handles the case where its expected Discount_Config__mdt record is missing — it should return a safe default rather than throwing.

Requirements

• Call the lookup with a region name that has no matching custom metadata record.
• Assert the method returns the documented default (e.g. 0) instead of raising an unhandled exception.

Problem Statement

Write a test class IsolatedStepRunnerQueueableTest that verifies IsolatedStepRunnerQueueable continues processing the rest of its Ids even when one record in the middle of the list fails to update (e.g. an invalid Id).

Requirements

• Build a list of Ids where the middle one is deliberately invalid/unresolvable.
• Enqueue the job inside Test.startTest()/Test.stopTest() so it actually executes synchronously by the time the test continues.
• Assert that the valid records on either side of the failure were still processed.