テストクラスのアンチパターン『ダミークラス大作戦』についてです。Apex開発を行うときテストクラスを用意する必要があり、テストのカバー率が組織全体で75%以上になっていないと本番環境にリリースできないようになっています。
その昔テストクラス作るのはコストになるからということでダミークラス大作戦が考えられました。意味のないコードを数万行程度用意してそれをテストで通すことで強制的にカバー率をあげることができるテクニックです。
Developer組織で実際に試してみると確認できると思いますが、状況によっては通常のテストクラスを一切用意しなくてもカバー率を80%近くまで向上させることができると思います。
この方法ですがやってはいけないアンチパターンとなっていて推奨されないテクニックとなっています。
アンチパターンの理由としてダミークラスでテストカバー率を上げる方法はSalesforceに負荷を与えてしまいます。負荷を与えるというと利用者には関係無さそうとなるかもしれませんが、Salesforceではパフォーマンスチェックや組織が正常に利用できる状態かチェックする仕組みがきちんと用意されています。
そのため1つの組織で異常な負荷を発生させていると、異常な負荷が発生しているので確認してください。とチェックが入る...かもしれません。(実際にあるかはわかりませんが..)
負荷を与えるという裏側の理由以外にもダミークラスを用意するやり方で組織を作り込むことで大きなトラブルが発生することも想定されます。
ダミークラスをつかったカバー率向上ですが、無限に対応できるわけではありません。数千行のコードのカバー率を75%以上にするために2万行のダミー処理が必要だったとして、2万行のコードをカバーするため5万行用意しても75%を保持できなくなっていきます。
そのため下記のケースが発生すると思います。
「開発時間短縮のためテストクラスは一切用意しません。そのかわり目視のテストでバグがないかを担保します。」というようなプロジェクトが始まり、予定どおり目視の検証だけでバグのないシステムを完成させて納品できました。
数年後、その組織で新たなプロジェクトが立ち上がることになり、今度はその分野に強い別の会社に依頼して開発を進めることになりました。そのプロジェクトではApexクラス毎にテストクラスを用意して開発した部分についてはきちんとカバーするように進めていきました。ですが組織のコード量が増えたことでダミークラスの効果が薄まり本番環境にリリースできなくなります。
こうなると大変です。新しいプロジェクト側では正しくテストクラスを用意しているのでこれ以上をカバー率を向上させることはできません。組織全体のコード量が多くなったため、ダミークラスの処理を増やす方法でも効果がでません。では最初の会社に依頼して用意してもらうかとなっても数年経っていると対応が難しくなると思います。追加工数を用意してテストクラスをつくり始めても当時気づかれなかった小さなバグがたくさん見つかりApexクラス側の改修が必要になることもあると思います。
このようにダミークラスをつかったやり方は一時的にうまくいくように思えても将来的に大きなトラブルにつながります。また目視のテストには当然時間が必要です。開発フェーズ→テストフェーズときちんと時間がとれるプロジェクト中は問題ありませんが、保守期間にちょっとした機能追加を依頼したくなったときに、目視ですべての機能を再検証する時間を作るのは難しいため、結果として調査しないとその機能の実装をして既存機能に影響がないかわかりません。機能追加後に検証工数がかかりますとなってしまいます。そうなった組織は最終的に何もできなくなり数年後には使えない組織となると思います。セールスフォースは使いづらいね。別のプラットフォームで一から作り変えようという選択しか取れなくなってしまうと思います。
テストクラスを用意したらバグの無いシステムが完成するかというとそうはなりませんが、開発中にちょっとしたバグに気づくことはできますし、将来身動きの取れないシステムが完成するのは回避できると思います。
ということでテストクラス作成工数を省略するダミークラス大作戦を前提としたやり方はやめておくのがオススメです。
