Starting November 20, the site will be set to read-only.
On December 4, 2023,
Apex Code Development (90768)
General Development (55146)
Visualforce Development (37251)
Lightning (18265)
APIs and Integration (17146)
Trailhead (11680)
Formulas & Validation Rules Discussion (11337)
Other Salesforce Applications (8116)
Jobs Board (6655)
Force.com Sites & Site.com (4842)
Mobile (2694)
You need to sign in to do that
Don't have an account?
sihmeieos こんにちは。いつもお世話になっております。
テストの度に煩わされるのが、テストデータの作成です。
メソッドごとにテストデータを作成するよう、ソースを書いても良いのですが、ソースコードの量が多くなると見づらいですし、
他に良い方法は無いかと悩んでいました。
テストデータ作成専用のクラスを作成し、テストクラスからCallするようにすれば良いかとも思いましたが、
@isTestアノテーションを使って宣言したクラス・メソッドは全てprivateで無ければならないため、Call
できませんでした。
通常のpublicなクラスだとinsertをすると実データが作成されてしまうと思います。
テストデータを作成する上で、以下のようなことが可能な良い方法は無いでしょうか。
・テストデータの管理が容易。
・テストデータの作成ロジックが集まっている。
わたしも同様に行き詰った結果、下記のような方式でやっています。
テストデータ作成ロジック専用のpublicクラスを作成。(もちろん@isTestアノテーションはつけないです。)
テストクラスでは、上記クラスのメソッドをcallしてデータを作成した後にテストを実行しています。
(testMethodからcallした場合にはCUDはされないのを利用して。)
マスタデータなどは一度作れば、使いまわせますし。
デメリットをあげるとしますと、
2はtestMethodからcallしているので大概クリアできるので問題ないと思います。
むしろカバレッジが足りない場合は、テストデータ作成ロジックが怪しいかと。
1は感覚の問題ですので・・・
私もue123さんと同じですね。
testMethod用のクラスとは別にTestCommonクラスを作って、そこに作ったデータ作成用のpublicなメソッドをtestMethod毎に呼んでいます。
public、private関わらずtestMethodから実行されたDML処理は全てロールバックされます。
ついでに言うとtestMethodの初期処理として、テストデータ作成以外に「組織に登録されているレコードの削除処理」なんかをしておくこともあります。
というのは、組織内にデータがある状態でテストを走らせると、組織内に登録されているデータに依存したテストになってしまう可能性があるからです。
自分で意図していなくても意外とsandBoxでは通ったのに本番では通らないなんてことがあります。
ただ、全削除する場合はデータ容量やtestMethod内でのガバナーなどに注意する必要があります。
（トランザクションデータ数が多いと苦労します）
余談：testMethod内でのDML処理はロールバックされるが、自動採番項目の連番はロールバックされないみたいです・・・
ueさん
遅くなりましたが、replyありがとうございました。
@isTestアノテーションをつけないと、データがcommitされてしまうと勘違いしていました。
（どこかにtestMethodからのCallではデータはCommitされない旨記述されてました？）
テストデータ作成用クラスをつくり、以下のようにしてみました。
Trigger
↓
Testクラス
テスト実施前にテストデータ作成用メソッドをCall
テスト実行
Testクラスのメソッドで、都度テストデータ作成用クラスをCallしているので、テストデータの重複
などが発生するため、テストデータの存在をチェックするロジックが必要になって効率が悪いですが…。
ikouさん
遅くなってしまいましたが、Replyありがとうございました。
仰る通り、環境に登録されているデータの相違によってテスト結果が違ってしまうこともあるので、データ削除処理を
最初に走らせておくのは良いですね。
テストデータ作成用クラスをつくる上で、私もSandBoxと運用組織で登録されているデータが異なるために違う結果が
出てしまって悩んでしまいました。
あと、自動採番項目の連番のロールバックはできるようにしてもらいたいですね・・・。
テスト時だけではなく、通常の時もUIからの項目のデータ型変更ではなく、明示的に連番を初期化するという操作
で実施したいです。
sihmeieosさん、ikouさん
私もikouさん同様、先にテストの対象範囲のデータを削除しております。
記載漏れで余計な手間をおかけし失礼しました。
ロールバックの件ですが下記に記載されております。
Testing Apexの章で説明がないのが「どうなの？」と思いますが。
http://www.salesforce.com/us/developer/docs/apexcode/Content/apex_qs_HelloWorld_add_tests.htm
私は「自動採番項目」は欠番が発生しても構わない時だけ使っていますので、気にしてません
が、シーケンスなのでしょうね。
ue123
早々に資料を教えていただき、ありがとうございます。
ご紹介いただいた文章の" The method validateHelloWorld is defined as a testMethod
. This means that if any changes are made to the database, they are automatically rolled back when execution is complete."という箇所がロールバックに関して明記されている部分だと思います。
私、これは、テストメソッドに記載している処理のみがロールバックされ、テストメソッドからコールしている他クラスの処理はコミットされると思い込んでいました。よくよく考えるとどちらも同じことなのですが…。
"Force.com Apex Code Developer's Guide"（spring'10のp.125）には、以下のようにだけ記載されているようです。
"Unit test methods take no arguments, commit no data to the database, send no emails, and are flagged with the testMethod keyword in the method definition."