テストを行う理由を学ぶ
学習の目的
この単元を完了すると、次のことができるようになります。
- 単体テストとは何かを定義する。
- 単体テストを記述する理由を説明する。
- 開発者の向上にテストがどのように役立つか説明する。
メモ
日本語で受講されている方へ
Challenge は日本語の Trailhead Playground で開始し、かっこ内の翻訳を参照しながら進めていってください。Challenge での評価は英語データを対象に行われるため、英語の値のみをコピーして貼り付けるようにしてください。日本語の組織で Challenge が不合格だった場合は、(1) この手順に従って [Locale (地域)] を [United States (米国)] に切り替え、(2) [Language (言語)] を [English (英語)] に切り替えてから、(3) [Check Challenge (Challenge を確認)] ボタンをクリックしてみることをお勧めします。
翻訳版 Trailhead を活用する方法の詳細は、自分の言語の Trailhead バッジを参照してください。
はじめに
開発者はコードを記述します。単体テストとは、単体テストという追加のコードを記述するソフトウェアの開発手法です。こうしたテストでは、既知の入力パラメーターを使用してビジネスロジックのコードを実行し、期待どおりの結果が出力されることを検証します。
単体とは、テスト可能な最小限の論理コードです。メソッドの場合もありますが、通常はメソッドの一部です。さまざまな単体テストで同じコードが実行されることが多々ありますが、コードの実行時の論理パスが異なります。たとえば、ある単体テストで if/else ブロックの else 条件を実行し、別のテストで if 条件を実行することがあります。
ソフトウェアのテストは、単体、機能、インテグレーションの 3 つに大別されます。機能テストとインテグレーションテストでは、コードの機能性、または外部システムと統合するコードの機能のいずれかに焦点が当てられます。単体テストは機能テストとよく似ていますが、より具体的で、テスト可能な最小限のコードを対象とします。たとえば、単体テストで、特定の条件を満たした場合のメソッドの出力を確認することがあります。また、単体テストはある程度自動化されていることが多く、スケジュールに従って、あるいはイベントに応じて実行されます。たとえば、Salesforce では開発環境から本番環境にリリースするときに単体テストを実行します。
このモジュールでは、Lightning プラットフォームで役に立つ単体テストを記述するための詳細を説明します。どの単元にも、概念を紹介する短い動画と、そのスキルの習得に役立つハンズオン演習が用意されています。準備はいいですか? では始めましょう。
テストする理由
テストを記述する理由は少なくとも 3 つあります。次の動画で、テストを行う理由を簡単にご紹介します。
数字は嘘をつかない
長い目で見れば、テストを記述することで開発時間を短縮できます。IBM のアナリストらがバグの修正にかかる相対的なコストに関する 2010 年の論文で、ソフトウェア開発ライフサイクルのさまざまな時点でバグの修正に要する時間を検討しています。また、その結果をわかりやすく説明するために、バグの修正にかかる相対的なコストを見積もっています。つまり、ソフトウェア開発ライフサイクルの各フェーズで同じバグが検出された場合に修正に要する時間を論じています。
結果は明白です。設計フェーズでバグが検出された場合の相対的なコストは 1 時間でした。それに対し、実装フェーズ (または開発中) は、同じバグの修正に 6.5 時間の相対的なコストを要しました。機能テスト時は、バグの修正の相対的なコストが 15 時間に跳ね上がりました。相対的なコストが 6.5 時間、あるいは 15 時間であれば対処可能です。何よりも懸念されるのは、この同じバグを本番環境で修正する場合の相対的なコストです。本番環境になると、バグの修正に要する相対的なコストが 100 時間に激増します。
研究者らは当然のごとく、本番環境に達する前であればバグを手早く修正できると結論付けています。
もちろん、テストにも時間がかかります。けれども、バグの修正によって創造的な問題解決に費やす時間が奪われることから、できるだけ早い段階で時間を取り、バグを見つけて修正すれば、後々の時間が節約されます。実際のところ、テストによって本番環境のバグが 1 つでも阻止されれば、開発期間の短縮につながります。
ソリューションが機能するだけでは不十分
時間の節約は素晴らしいことですが、テストを記述するさらに重要な理由があります。テストによって開発者として向上できることです。開発者が身をもって (繰り返し) 学ぶべき教訓の 1 つが、ソリューションが機能するからといって本質的に優れているとは限らないことです。ソリューションが機能する場合には、開発者が往々にしてソリューションについて突き詰めて考えなくなるという危険性をはらんでいます。こうしたソリューションによって当座の問題が解決されても、バグの再発や新たな不具合 (製品全体を悪化させる変更) を伴うことがあります。このようなソリューションが、大半の技術的負債の原因になっています。
テストを行えば、機能するソリューションと優れたソリューションを区別できます。機能するソリューションは、テストしにくいことがあります。概して、テストしやすいソリューションには構成可能な小規模なメソッド、的を絞ったクラス、明確に定義されたインターフェースといった共通点があります。この特徴に聞き覚えがあるとしたら、この 3 つは適切に記述された管理可能なソリューションの特徴でもあるためです。テストを念頭に置いてコードを記述するということは、管理しやすいコードを記述するということです。また、管理しやすいソフトウェアを記述する方法を学べば、開発者として向上することができます。
一斉テスト
テストを実行する最初の 2 つの理由は、どの言語やプラットフォームにも当てはまります。Salesforce には、テストを記述するもう 1 つの理由があります。Salesforce プラットフォームでテストを実行すれば、プラットフォーム上の他のすべてのユーザーにメリットがあることです。Salesforce では、各回のメジャーリリースの前に、プラットフォームの現在のバージョンとリリース予定のバージョンの両方で不具合を調べる回帰テストを実行します。この回帰テストでは、各組織ですべてのテストを実行します。Salesforce の回帰テストは、各自の組織用に記述したすべての Apex テストクラスが対象です。
このテストを「ハンマー」と呼んでいます。ハンマーの実行時に、6,000 万超のテストを 2 回実行します。テストによってプラットフォームのバグの再発や新たな不具合が特定されるため、プラットフォーム上のすべてのユーザーの役に立ちます。ささやかな単体テストに対する見方が変わったのではないでしょうか?
テストする理由を再考する
繰り返しになりますが、なぜテストするのでしょうか? 時間を節約し、開発者としてのスキルを向上させ、優れたソフトウェアを構築すると同時に、同僚の開発者の役に立つためです。テストを行うことで、関心のある問題の解決に多くの時間を費やせるようになります。