SF-PD2 Testing, Debugging, and Deployment Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✓

  Create a data factory class to handle object creation and common test data scenarios.

  Why this is correct

  Centralizing test data creation in a dedicated factory class promotes reusability and simplifies maintenance. When schema changes occur, you only need to update the factory rather than dozens of individual test classes. This pattern is a hallmark of professional Salesforce development and significantly reduces test suite fragility and technical debt.

• ✗

  Insert test records within the @isTest methods to ensure data isolation for every test run.

  Why it's wrong here

  Hardcoding record insertion directly into individual test methods violates DRY principles and creates significant maintenance overhead. If an object's required fields change, every test method would require manual updates. Data factory classes should be utilized instead to encapsulate logic and ensure consistency across the entire unit testing suite.

• ✗

  Use System.runAs() to test user permissions and visibility settings for every individual record.

  Why it's wrong here

  While System.runAs() is useful for testing specific permission sets, using it for every single record operation introduces unnecessary overhead and slows down test execution. Developers should only use it when specifically verifying security model enforcement, not as a general practice for all data verification tasks within unit tests.

• ✓

  Perform bulk testing by inserting a list of 200 records to verify governor limits.

  Why this is correct

  Testing with a single record is insufficient because it fails to reveal potential SOQL or DML limit violations that only occur at scale. By inserting a batch of 200 records, developers ensure that their code handles Salesforce bulkification requirements correctly, preventing runtime errors in production when users perform mass operations.

• ✗

  Use the SeeAllData=true annotation on all test classes to ensure full visibility.

  Why it's wrong here

  Using SeeAllData=true is a dangerous practice that links tests to the state of the organization's actual data. This often leads to brittle tests that fail randomly due to external factors. Unit tests should always be isolated from production data to ensure consistent, predictable results that do not depend on environment-specific records.