早くテストすればするほど、早くリリースすることができます。コード変更の影響について検証するために、ナイトリー/デイリーのビルドでユニットテストスイート全体が実行されるのを待つ必要はありません。コード変更の影響を受けるテストをすぐに把握し、安心してチェックインできる方法があります。
ユニットテストはずっと以前から業界でのベストプラクティスであり、開発チームがテストを足していくにつれて、テストスイートは大きくなる一方です。テストが統合レベルまたはコンポーネントレベルのテストにまで拡大するにつれて、実行に時間がかかるようになります。TDDのようなユニットテストの新しいトレンドでは、テストスイートは以前よりもさらに大きくなります。なぜなら、すべてのコードがテストに依存するためです。
多数のユニットテストからなる基盤を持つことは、確実なテストの基盤ともなりえますが、特にユニットテストが統合/コンポーネントレベルのテストにまで拡大するにつれて、テスト実行時間に大きな影響を与える可能性もあります。したがって、 何をテストするべきかを知る上で重要な点は、各コード変更の正確な影響、実行する必要のあるテスト、新たに必要になるテストを把握することです。
コードカバレッジを計算することは、何がテストされたのかを判断するための 1 つのものさしですが、それだけでは十分ではありません。テストごとにコードカバレッジを計算した後、ビルドごとのコードの変更とカバレッジを関連付けることで、真の効果を発揮します。このアプローチによってテスト影響分析が可能になります。テスト影響分析プロセスは、コード変更を検証するために実行するべきテストを正確に特定します。ソフトウェア開発チームは、Parasoft Jtestを使用してユニットテストのテスト影響分析を活用することで、IDEまたはCIプロセスを介してテスト作業に集中し、開発パイプラインを真に加速することができます。
テスト影響分析を簡単に
できるだけ早期にバグを見つけて修正できることは、テスト影響分析を行うことの主な利点です。テスト影響分析の結果をIDEに直接統合することで、開発者はワークフロー内でそのメリットをシームレスに活用し、 テスト作業を適切な場所に集中させ、関連コードへの間接的な影響も含めて、完全にテストできるようになります。
バグを早期に見つけて修正することが第一の目標ですが、開発者が簡単にテスト影響分析の結果を得られることには、他にも利点があります。
- 修正されたファイルのコードを実行するテストを強調表示し、必要なテストのみが実行されるようにする
- さまざまなソース管理システムおよびビルドシステムと統合でき、必要に応じて独自の環境をサポートするようにカスタマイズ可能
- テストとコード間の直接的な依存関係だけでなく、間接的な依存関係も特定して、変更による影響を完全にテストすることを保証
- 簡単な初期設定で、影響を受けたテストを自動的に識別して実行することができ、ユーザーはコードを変更して結果を確認するだけ
テスト影響分析とCIプロセスを組み合わせることで、さらに多くの時間を節約し、開発チームの労力をまさに必要な作業にだけ投入し、品質を確保することができます。開発およびビルド時間の最適化は、変更の処理に関するアジャイルの目標を達成する上で非常に重要です。
テストの焦点を絞り、より良いソフトウェアをスケジュールどおりにデリバリー
ソフトウェア開発ライフサイクルの後半にバグが見つかると、大幅なスケジュールの遅延を引き起こす可能性があります。バグは早期に見つけるほうがコストが低く修正が容易です。開発者は、どのテストを実行するべきかわからないことが多いため、テストをまったく実行しないか、実行したとしても不足していることがあります。この場合、テストスイート全体を実行するように設定されているビルドに頼らざるを得ません。そのため、開発者は自分が行った変更に関するフィードバック/検証結果がビルドプロセスから返ってくるまで待たなければなりません。そうではなく、テスト影響分析を活用することで、開発チームはコードをビルドにコミットして変更を検証する前に、適切なテストを見つけて実行することができます。
テスト影響分析は、テストの失敗を引き起こすコード変更について、開発者がいち早くCIプロセスからフィードバックを受け取れるということも意味します。開発マネージャーは、コードをチェックインする前にテストを実行するのが理想的だと考えていますが、これは徹底されないことがよくあります。さらに、マネージャーはコードがチェックインされたことでテストが失敗した場合、できるだけ早くチームに通知できるよう望んでいます。したがって、テスト影響分析は、開発者のデスクトップだけでなくCIプロセスでも行えることが重要です。
Parasoft Jtestの「影響を受ける単体テスト」ビュー
では、変更の影響は、実際にはどのように参照できるのでしょうか？IDEで開発者がコードを作成しているとき、Jtestの「影響を受ける単体テスト」ビューには、ローカルで変更されているコードを検証するために実行する必要があるテスト(動的に追加されていく)のリストが表示されます。あとは、影響を受ける個々のテストを右クリックして実行するか、影響を受けるすべてのテストを一括で実行するだけです。
Jtestは、影響を受けたテストの実行を追跡し、成功したテストと失敗したテストを明確に表示するので、再実行する必要があるテストや、失敗に対処する必要があるテストを容易に判断できます。すべてのテストが実行され、成功していれば、開発者はコードの変更により自信を持ってコードをコミットし、次の開発タスクに移行することができます。
このコーディング－テスト－フィードバック－修正というワークフローは、特に開発者のデスクトップの生産性が向上するよう設計されているため、ユーザーはローカルコードの変更を検証するために必要なテストを簡単に特定して実行できます。直接運用環境にデプロイする場合も、バグがエンドユーザーにまで届くのを防ぐことができます。複数のチームがプロジェクトに関わっている場合、コードがコミットされる前に適切なテストが実行されていれば回避できたはずの問題をトラブルシューティングし解決するために、他のチームが時間を無駄にすることがなくなります。
パイプラインツールの統合と補完
ツールは、既存のツールチェーンに簡単に統合できなければ役に立ちません。Parasoft JtestはGitやSVNだけでなく、他のソース管理システムで管理されているプロジェクトにも対応しています。IDEは、EclipseとIntelliJの両方に対応しています。 JtestにはMavenおよびGradleプラグインがあり、MavenまたはGradleビルドの一部としてテストを実行するCIビルドジョブに統合できます。
これらのプラグインは、ベースラインビルド（多くの場合は最後の夜間ビルド）以降に変更されたコードを特定し、そのコードを検証するために実行する必要のあるテストを判断して該当するテストだけを実行するので、テストスイートを完全自動化できます。これにより、チームは最新のコード変更に基づいてテストを実行するだけのCIジョブをセットアップし、場合によっては、CIジョブを実行するのにかかる時間を数時間から数分に短縮できます。
ベストプラクティスとして、チームは夜間に完全なユニットテストスイートを実行し、日中の（中間的な）ビルドではテスト影響分析を活用することができます。このように、Parasoft Jtestは実行時間が長いテストスイートを持つチームにとって特に有益です。チームは、コードをコミットしてから数分以内にテストの結果を得ることができ、真のCIを実現できます。このような仕組みがない場合、適切でないコードの変更によって発生したレグレッションが、すぐに捕捉されずに運用環境に混入したり、他のチームメンバーの作業を妨げたりする可能性があります。
開発チームは、テストする必要があるリソースにリソースを集中させることにより、迅速かつ効率的にテストを実行し、チェックインしているコードを常に検証し、バグやセキュリティ上の脆弱性がビルドに入る前に捕捉できます。
（この記事は、開発元Parasoft社 Blog 「Get immediate feedback about code changes using test impact analysis」2018年11月15日の翻訳記事であり、Jtest 10.4.1の機能に関する内容が含まれます。）
Parasoft Jtestについて
Java対応静的解析・単体テストツール Parasoft Jtest
Jtestは、テスト工数の大幅削減とセキュアで高品質なJavaシステムの開発を強力にサポートするJava対応テストツールです。1,000個以上のコーディング規約をもとにソースコードを静的に解析し、プログラムの問題点や処理フローに潜む検出困難なエラーを検出します。さらに、JUnitを用いた単体テストについて、作成、実行、テストカバレッジ分析、テスト資産の管理といった単体テストに係る作業をサポートし、単体テストの効率化を促進します。
