The decision before the tool: Test data design
Why this deserves attention
Good test data communicates the business scenario and remains independent of org state. Clarity here reduces both delivery risk and the long-term cost of ownership.
Large shared factories hide intent and create coupled tests that break when unrelated setup changes. On 31 October 2024, this archive entry records the principle as a practical design concern rather than a product announcement.
Clarify the decision
Look at test data design through the business decision that must be clear before choosing a Salesforce feature. The objective is not to introduce more process; it is to expose the few decisions that determine reliability, ownership and future change.
Create only the records required for the behaviour, use focused builders and make relationships obvious in the test. Record the decision close to the solution so that delivery, support and future architecture reviews work from the same intent.
What good looks like
Failures point quickly to the behaviour under test instead of an opaque data fixture. The team can describe the expected behaviour, the owner, the evidence of success and the response when reality differs from the design.
A useful next step is to review one live implementation against this principle, identify the largest unowned assumption and turn it into a bounded improvement with a measurable outcome.
Official reference
Salesforce Apex Developer Guide