ApexBlueprint
Declare the final shape of your data, and let the framework handle dependency resolution and DML. An OSS for Apex test data generation — turning integration test assembly from a procedure into a design.
Why ApexBlueprint
From Procedures to a Map of DataDeclarative Data Specification
The TestDataFactory pattern, widely used in Salesforce integration testing, ends up as procedural code: "create an Account, create a Contact under it, then an Opportunity referencing it ..." Parent IDs are passed around in variables, and as scenarios diverge, methods like createOpp1 / createOpp2 proliferate until the final data structure is no longer readable from the code at a glance.
ApexBlueprint replaces this procedure with "declaring the final shape of the data as a single block". The domain layer draws a per-record blueprint with SBlueprint, and parent-child relationships or value copies are simply declared as "dependencies" via withChildren / use. You don't write a single line of code that carries a parent ID around in a variable.
Once assembled, the blueprints are handed to SOrchestrator, which resolves their dependencies with a topological sort and performs the DML inserts in the correct order. The shift from "creating data" to "designing data" happens without interruption.
SBlueprintSOrchestrator.create()Core Building Blocks
Two Core Components
SBlueprint
A method chain that declares a "blueprint" for a single record. Combine of / set / template / alias / use / withChildren / times to handle parent-child structures, bulk generation, and value copying — all through a single API.
SOrchestrator
An execution engine that reorders the added blueprints via topological sort and inserts them in the correct DML order. With start / add / create / getByAlias, execution and result retrieval are complete in one flow. Circular dependencies and duplicate aliases are detected and raised.
Why This Design
ApexBlueprint's Distinctive Design
Code structure mirrors parent-child relationships
With nested withChildren, the indentation hierarchy of your code matches the "parent-child-grandchild" data hierarchy directly. Code that carries parent-child relationships in variables disappears entirely, so even hundreds of lines of test data are readable at a glance: you can see "what structure of data is ultimately created" without scanning back and forth.
Orchestrator handles dependency resolution
SOrchestrator uses a topological sort to automatically decide "which records to insert first" and "where to copy parent IDs from". The "bucket relay" code that hands IDs around in variables disappears, and the test body becomes shorter and easier to read.
Escape flag hell with template + set
Common field sets are loaded via .template(...), and only the differences you actually want to verify in that test are overridden with .set(...). The method explosion of "createOppWithFlagA / WithFlagB / WithFlagC" and the parade of boolean arguments disappear, keeping the factory layer thin.
Bulk generation with times and {#}
.times(n) and the {#} placeholder let you write bulk-generated records with sequence numbers in a single line. Aliases can also embed {#}, so references like "the 3rd Contact under the 2nd Account" stay self-contained within the blueprint.
Where It Sits in Apex Stem
Where ApexBlueprint Fits in Apex Stem
ApexBlueprint plays the Test Data Factory role among the four OSS that make up Apex Stem. It enters the picture when real DML runs in the Handler integration tests of Handler-Usecase Architecture, and it sits at the core of the "Handler integration test ↔ ApexBlueprint" mapping in our test strategy.
- Handler-Usecase Architecture: The Handler integration testing context where ApexBlueprint is invoked
- Test Strategy: Integration tests built around
SBlueprint/SOrchestrator - ApexEloquent: The data access OSS that handles the unit testing side of the same strategy
- Apex Stem Introduction Guide: The 4-step working-code walkthrough
Start with the Developer Guide
The Developer Guide walks through prerequisites and installation, declaring single records with SBlueprint, and resolving dependencies + running DML with SOrchestrator — all with working code.