【Salesforce】Apexテストデータの作り方（Test Data Factory）｜毎回コピペをやめる最小テンプレ
※この記事にはアフィリエイトリンクを含みます。
Apexテストって、ロジックより先に『データ作成』で詰まりがちです。
自分も最初は、テストのたびに Account/Contact をコピペして、必須項目が増えた瞬間に全部崩れました。
で、問題はここなんですよ。
テストが落ちる理由が『機能の不具合』じゃなく『テストデータの作り方のブレ』になると、修正がしんどい。
ってことで、結論です。
結論：テストデータは『Factory（工場）』に寄せて、作り方を固定する。
これだけで「環境差で落ちる」「毎回テストが長い」「修正が連鎖する」をかなり減らせます。
※ 次に詰まりやすいのは「非同期（Queueable/Batch）のテスト」です。型を先に押さえると一気に楽になります。
Contents
Test Data Factory とは？
Test Data Factory は、テストで使うレコードを作る処理を『1か所に集約する』考え方です。
テスト側は本来、こうありたいです。
- 何を検証したいか（条件と期待値）だけを書く
- データ作成は短く済ませる
- 必須項目が増えても、直す場所は1か所
つまり『テストの土台を固定する』ための仕組みです。
まず問い（ここが痛い人向け）
いまのテスト、こんな状態になってませんか？
- テストクラスごとに同じデータ作成コードが散らばっている
- 必須項目が増えるたびに、複数テストがまとめて落ちる
- 直したつもりが別テストを壊す（修正が連鎖する）
心当たりがあるなら、Factoryに寄せた方が早いです。
Salesforce公式：Apexテストのベストプラクティス（テストデータはテスト内で作る）最小テンプレ：まずはこれだけでOK
いきなり“万能Factory”を作ると逆に死にます。
最初は『よく使う形だけ』を作るのが堅いです。
TestDataFactory（最小）
@IsTest
public class TestDataFactory {
// 取引先（Account）
public static Account createAccount(String name) {
Account a = new Account(Name = name);
insert a;
return a;
}
// 取引先責任者（Contact）
public static Contact createContact(Account a, String lastName) {
Contact c = new Contact(
LastName = lastName,
AccountId = a.Id
);
insert c;
return c;
}
// 商談（Opportunity）※必要になったら使う
public static Opportunity createOpportunity(Account a, String name) {
Opportunity o = new Opportunity(
Name = name,
AccountId = a.Id,
StageName = 'Prospecting',
CloseDate = Date.today().addDays(30)
);
insert o;
return o;
}
}
このテンプレの狙いは3つだけです。
・返り値でレコードを返す（後続の紐づけが楽）
・insertまでFactoryでやる（テスト側を短くする）
・引数は最低限（細かい分岐は必要になってから）
テスト側はこう書く（短くして検証に集中）
Factoryがあると、テストが『何を検証するか』に寄ります。
@IsTest(SeeAllData=false)
public class SampleServiceTest {
@IsTest
static void testSomething() {
Account a = TestDataFactory.createAccount('Test Account');
Contact c = TestDataFactory.createContact(a, 'Test User');
// ここに「検証対象」を置く（例）
// SampleService.doSomething(a.Id);
System.assertNotEquals(null, a.Id);
System.assertNotEquals(null, c.Id);
}
}
この形にしておくと、必須項目が増えたときに直す場所はFactory側に寄ります。
テストクラスを片っ端から直す地獄が減ります。
よくある失敗（ここだけ避ければ十分）
失敗1：テスト側のコピペが増える
最初は早いんですが、すぐ散らかります。
必須項目が増えた瞬間に、落ちるテストが増えて修正が面倒になります。
対策：データ作成はFactoryに寄せる。修正箇所を1か所にする。
失敗2：Factoryが最初から万能で巨大化する
引数が増えすぎると、使う側が迷います。
結果として『Factoryを呼ぶのが重い』状態になります。
対策：よく使う形だけ作る。足りなくなったら増やす。
失敗3：SeeAllData=true に逃げる
データ作成が面倒で SeeAllData=true に寄ると、環境差で壊れやすいです。
テストの安定性を上げたいなら、SeeAllData=false＋Factoryが堅いです。
もう一段だけ良くする（任意）
最小テンプレが動いたら、追加はこれだけで十分です。
- 共通の初期値を固定する（StageName/CloseDateなど、毎回同じならFactory側に寄せる）
- “セット作成”を1つだけ作る（例：Account＋Opportunityを1発で作る）
やりすぎると巨大化するので、セット作成は1〜2個までが堅いです。
まとめ
- Test Data Factory は『テストデータ作成の置き場』を1か所に寄せるやり方
- 最初は最小テンプレで十分（Account/Contact/Opportunity）
- テストは短くなり、検証に集中できる
- SeeAllData=false と相性が良く、環境差で落ちにくい
