To ensure tests are self-contained and have access to necessary records, data must be created within the test's transaction context.

A Test Data Factory (A) is a best-practice pattern that uses a dedicated Apex class to programmatically create and insert required sObject records. This approach promotes reusable, maintainable, and easy-to-understand test setups.

For large data volumes, as specified by the "500 records," the Test.loadData() method (C) is the most efficient and recommended approach. It populates records by reading from a CSV file stored as a static resource, bypassing per-transaction DML limits and simplifying the setup for extensive, static datasets.

1. Apex Developer Guide

"Creating Test Data for Apex Tests": This section explicitly details the two primary methods for creating test data. It describes using a "test utility class" (a Test Data Factory) for reusable data creation and the Test.loadData method for loading large sets of records from a static resource.

Quote/Concept: "A more useful and reusable method for creating test data is to use a test utility class... For some scenarios

you need to load a large set of data... You can do so by using the Test.loadData method."

2. Apex Developer Guide

"Isolation of Test Data from Organization Data in Unit Tests": This section explains that tests run in isolation by default and explicitly warns against using @IsTest(SeeAllData=true).

Quote/Concept: "Using @IsTest(SeeAllData=true) isn’t a best practice because it turns off data isolation for your tests and can make them harder to maintain and deploy."

3. Apex Developer Guide

"Enforcing Sharing Rules": This section defines the purpose of the with sharing and without sharing keywords

clarifying that their function is related to record-level security

not test data isolation.

Quote/Concept: "The with sharing or without sharing keywords specify the sharing mode for a class." This confirms its irrelevance to making data visible to a test.