ApexBlueprint
「データの最終状態」 を宣言的に書いて、 依存解決と DML 挿入はフレームワークに任せる Apex 向けのテストデータ生成 OSS。 結合テストの組み立てを、 手続きから設計に変えます。
Why ApexBlueprint
データの「組み立て手順」 から「地図」 へDeclarative Data Specification
Salesforce の結合テストで広く使われる TestDataFactory パターン は、 「Account を作って、 そこに紐付く Contact を作って、 さらにそれを参照する Opportunity を作って...」 という 手続き的なコード を書き下す形になります。 親子の ID を変数で持ち回り、 シナリオ違いごとに createOpp1 / createOpp2 ... とメソッドが増殖し、 最終的にどんなデータ構造になるかがコードから一目で読み取れなくなっていきます。
ApexBlueprint は、 この手続きを 「データの最終状態をひと塊で宣言する」 形 に置き換えます。 ドメインは SBlueprint でレコード単位の設計図を描き、 親子関係や値のコピーは withChildren / use で「依存」 として宣言するだけ。 親 ID を変数で持ち回るコードは一行も書きません。
組み立てた blueprint 群は SOrchestrator に渡せば、 依存関係をトポロジカルソートして正しい順序で DML 挿入してくれます。 「データを作る」 から「データを設計する」 への移行を、 ノンストップで体験できます。
SBlueprintSOrchestrator.create()Core Building Blocks
2 つのコア機能
SBlueprint
単一レコードの「設計図」 を宣言するメソッドチェーン。 of / set / template / alias / use / withChildren / times を組み合わせて、 親子・量産・値のコピーを一つの API で扱えます。
SOrchestrator
追加された blueprint 群を トポロジカルソート で並べ替え、 正しい順序で DML 挿入する実行エンジン。 start / add / create / getByAlias で実行と結果取得まで完結します。 循環依存や alias 重複は検出時にエラー。
Why This Design
ApexBlueprint の独自設計
コード構造が親子関係をそのまま視覚化
withChildren のネストで、 コードのインデント階層がそのまま「親-子-孫」 のデータ階層と一致します。 親子関係を変数で持ち回るコードが一切消えるので、 数百行のテストデータでも「最終的にどんな構造のデータが作られるか」 が一目で読み取れます。
依存関係の解決を Orchestrator が肩代わり
「どのレコードから insert すべきか」 「どこから親 ID をコピーすればよいか」 を SOrchestrator がトポロジカルソートで自動決定します。 ID を変数で持ち回る「バケツリレー」 のコードが消え、 テスト本体が短く読みやすくなります。
template + set でフラグ地獄から解放
共通のフィールドセットは .template(...) で取り込み、 そのテストで本当に検証したい差分だけを .set(...) で上書きできます。 「createOppWithFlagA / WithFlagB / WithFlagC」 のようなメソッド増殖や、 引数のブール値羅列がなくなり、 ファクトリ層が薄く保てます。
times と {#} プレースホルダで一気に量産
.times(n) と {#} プレースホルダで、 連番つきの量産レコードが 1 行で書けます。 alias にも {#} を埋め込めるので、 「2 件目の Account に紐付く 3 件目の Contact」 のような参照も blueprint 内で完結します。
Where It Sits in Apex Stem
Apex Stem における位置づけ
ApexBlueprint は Apex Stem を構成する 4 つの OSS のうち、Test Data Factory を担います。 Handler-Usecase Architecture の Handler 結合テストで実 DML を流すフェーズに登場し、 テスト戦略 の「Handler 結合テスト ↔ ApexBlueprint」 の対応を担う中核です。
- Handler-Usecase Architecture: ApexBlueprint が呼ばれる Handler 結合テストの位置づけ
- テスト戦略:
SBlueprint/SOrchestratorを中心に据えた結合テスト - ApexEloquent: 同じテスト戦略の単体テスト側を担うデータアクセス OSS
- Apex Stem 導入ガイド: 動くコード付きの 4 ステップ
Start with the Developer Guide
開発者ガイドでは、 事前準備とインストールからはじめて、 SBlueprint で単一レコードを宣言する、 SOrchestrator で依存解決して DML を流す、 までを実際のコードで通します。