Salesforceに特化した情報をお届けします

そもそもApexとは？

Apexとは、Salesforceが提供するJavaに似た、オブジェクト指向のプログラミング言語です。Apexには特徴として、Salesforceで利用するために使いやすいように考えられている、というところがあります。

例えば、sObjectレコードのリストを返す、インラインのSalesforceObjectQueryLanguageとSalesforce ObjectSearchLanguageのクエリが標準でサポートされています。

また、変数や式の構文、ブロックや条件ステートメントの構文など、広く周知されたJavaのイディオムに基づいており、SalesforceApexが新しい要素を導入するとなれば、理解しやすい構文とセマンティックを使用してLightningプラットフォームの効率的な使用を促すため、簡潔で記述しやすいコードを作成することなども、使いやすいポイントの1つです。

開発時にテストを行う意味

長期間に及ぶ開発を正常に行うために、テストは重要な部分を占めています。

それは、実際にプログラムを運用し始めると、想定していなかった操作や、運用をユーザーが行う可能性があるためです。
これらのことは、単純にプログラミング作業をしているだけでは思いつくはずもないようなことも多いため、テストを行うことで様々なシチュエーションで正常に動作するか検証することが重要となるのです。

テストの重要性は、もちろんSalesforceApexでも同じですが、Apexでは「ApexTestFramework」により、Apexコードでのテストが簡単にできるようにされています。
ApexTestFrameworkとは、Apexでの単体テストの記述や、実行、結果の確認などの取得を可能にするものです。

テストの種類

構築したプログラムが正常に作動するか確かめる役割を持つテストですが、これにはいくつかの種類があります。

今回はその中でも、「単体テスト」「結合テスト」「システムテスト」の3つを簡単にご紹介します。

単体テスト

単体テストとは、構築したプログラムの1つずつをテストし、正常に動作するかの検証を行うものです。

正常に動作するかのみではなく、機能や性能、また運用に最適化されているかなども確認します。

結合テスト

結合テストとは、単体テストで確認した複数のプログラムを組み合わせて、正常に動作するかを検証します。

この中には「状態遷移テスト」と呼ばれるものも含まれており、これは、状態遷移図や状態遷移表などを用いて行われるテストです。

同じテストデータを流した場合、通常であればシステムは同じ動作をしますが、状態によって全く違う動作をするものも存在します。こういったシステムをテストすることを「状態遷移テスト」と呼びます。

システムテスト

システムテストとは、「単体テスト」と「結合テスト」などの後に、すべてのプログラムとハードウェアも合わせて、システム全体が正常に動作するか確認することをいいます。

システムテストは様々な種類が存在し、修正や変更などをした後に変更箇所が正常に動作するか確認する「確認テスト」や、脆弱性の確認、ユーザビリティの確認などを行う「評価テスト」、処理能力などを確認する「負荷テスト」などがあります。

このテストは、基本設計の段階で決定した仕様を満たしたものができているかどうか確認するために行われます。このテストが完了すると、ユーザーにリリースされ、「運用テスト」のフェーズに移行していきます。

Apex単体テストの利点

上記のように、システムの開発などにあたってプログラムを構築する際には、テストを行うことが必須となりますが、Apexの単体テストを利用する際の利点とは何なのでしょうか。

まずは、クラスやトリガが望んだとおりの動作をするか確認できることが、利点として挙げられます。
また、一連の「回帰テスト」を用意することで、クラスやトリガが更新されるたびに再実行することができるため、システムやアプリケーションが更新されたときに既存の機能が正常に動作するかを確認できます。

本番組織に高品質のシステムやアプリケーションを配信することで、本番ユーザーの生産性の向上が見込めたり、パッケージ登録者に高品質のシステムやアプリケーションを配信することで、顧客の信頼が高まることなども利点として挙げられます。

そして、Apexを本番組織にリリースする際や、Apexをパッケージとして顧客に配布する場合のコードカバー率要件が満たされるということも重要な利点の1つになります。

コードカバー率要件とは

コードをリリースする前か、LightningPlatformAppExchange用にパッケージ化する前に、Apexコード全体の75％以上がテストで合格していなければなりません。
さらに、各トリガについても何らかのテストを行う必要があり、これらがリリースのための要件となっています。

注意しなければいけないのは、この要件を満たすことを目的として、テストを記述してはいけないということです。
正常、異常のテストケースや一括レコード処理など、一般的な使用事例をテストすることが求められています。

Test Methodの構文

Test Methodは引数を取らずに、以下の2つの構文を使用します。

@isTest static void testName() {
    // code_block
}

@isTest static void testName() {

// code_block

}

static testMethod void testName() {
    // code_block
}

static testMethod void testName() {

// code_block

}

[testMethod]キーワードの代わりに、[isTest]アノテーションを使用することで、アノテーションでパラメータを指定することが可能となり、柔軟性が向上します。

TestFrameworkでは常にTestMethodにアクセスできるようになっているため、TestMethodの表示は考慮されず、TestMethodを、公開か非公開どちらで宣言しても違いがないため、構文ではアクセス修飾子が省略されています。

コードカバー率を高める

テストを記述するときに意識するべきことは、できるだけ高いコードカバー率を達成できるようにすることです。

これは、LightningPlatformでリリースするときやパッケージに要求される最低値である75％を目標とせず、より高い数値を目指すべき、ということです。

場合によっては、すべてのクラスメソッドのTestMethodを記述したにもかかわらず、コードカバー率が100％にならないこともあります。原因として考えられることの1つは、条件付きコード実行です。

条件付きコード実行のすべてのデータ値がカバーされていなければ、コードカバー率が100％にならないこともあります。

例えば、クラスメソッドに[if]ステートメントがあり、評価条件を満たすかどうかで異なる分岐が実行されるといった場合に、一部のデータ値が無視される傾向があります。TestMethodでは、こうした異なる値を考慮しなければなりません。

ロールバックとテストデータについて

TestMethodで作成されたSalesforceレコードは、データベースにコミットされず、テストの実行が終了すると、レコードはロールバックされます。
このロールバックにより、テスト実行後にテストデータをクリーンアップする必要がないため、効率化につながります。

Apexテストには、User、Profileオブジェクトなどの設定やメタデータオブジェクトへのアクセス権を除き、組織に既存のデータへのアクセス権がありません。
そのため、テスト用にテストデータを設定します。
テストデータを作成することで、テストがより確実なものとなり、組織のデータの変更などによって起こるエラーを防止できるようになります。
テストデータは、TestMethodで直接作成するか、ユーティリティテストクラスを使用することで作成できます。