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.