テストの自動化のピラミッド

最新のソフトウェアエンジニアリング、アジャイル開発、および DevOps プラクティスは、パイプラインアプローチをベースとしており、さまざまな自動化レイヤーに基づいて、機能や変更リクエストがパイプを介してビルドされます。テストの自動化プロセスは、貴重なソフトウェアを体系的に提供するための重要な鍵の 1 つです。
テストの自動化にはいくつかのレイヤーがあり、自動化のコスト、テストを実行する頻度と速さ、テストの実行場所 (どの環境で実行するか)、有益/効果的なチェック方法などの要因に応じて、パイプラインに価値を付加します。
次の画像は、ユニット（単体）テストを最も速く、最も少ないコストで実行する場合の理想的なテスト自動化レイヤーを表しています。一方、UI (End-to-End) テストは、より多くの時間とコストがかかります。

実際の各テストの配分はチームによって異なりますが、各テストの特定のアプローチに費やす労力については、特に GeneXus ではこのピラミッドを念頭に置いておく必要があります。

理由

ユニットテストは GeneXus アプリケーションにおいて最も重要なテストレイヤーです。これには主に 3 つの理由があります:

信頼性が高く、高速: ユニットテストは、プロシージャーで実行されるビジネスロジックの数に応じてミリ秒単位で実行されます (通常は SQL/DB の回数によって異なります)。
作成とデバッグが容易: GeneXus IDE 内で非常に容易にテストを作成およびデバッグできます。また、結果からエラーが分離されます。
開発者にただちにフィードバックを提供: プロシージャーが変更され、ビルドされるたびに、GeneXus は開発環境で自動的にテストを実行します。テストが不合格の場合、ユーザーにただちにフィードバックが提供されます。

さらに、すべての GeneXus 開発者は、いくつかのプロシージャーを記述した後、何らかの方法でプロシージャーを実行またはデバッグする必要があります。これまでの入出力テストでは、独自に作成した Web パネルや UI を使用し、さまざまな値を入力して出力を評価していました。このようなテストを、GeneXus に付属の新しいテスト機能を使用してナレッジベースの重要な資産とすることで、これまでかかっていた労力を軽減 (および自動化) することができます。
ただし、一部の機能が、単体では期待どおりに機能しても、システム全体 (さまざまなコンポーネントと統合) ではバグが発生する可能性があります。GeneXus アプリケーションは、SOAP または REST API を通じてサービスを公開するように設計されていることが多く、ビジネスロジックをあわせてテストするための重要なエントリーポイントが提供されています。そのため、API/サービスのテストは、できるだけ自動化することをお勧めします。
API の自動化によって、次のメリットがもたらされます:

高速で実行
主要な機能のテスト (UI は不使用)
CI/CD パイプラインへの統合が容易

主要なビジネスロジックが GeneXus のプロシージャーやデータプロバイダー内にカプセル化されている場合、最高レベルの ROI でユニットテストのメリットを得ることができます。一方、テスト対象のロジックがプロシージャー内ではなく、パネル (GeneXus の Web パネルや SD パネルなど) にカプセル化されている場合、別のアプローチで機能をテストする必要があります。
そのため、UI テストが最後のレイヤーとなります (これまで GeneXus で推奨されていたアプローチ)。UI テストの自動化は不確実になりがちで、テストのインフラストラクチャ、データ、使用するフレームワーク、ブラウザーのバージョンに大きく依存しますが、実際のユーザーの操作をシミュレートする方法はこれしかありません。
UI テストの自動化のメリットを最大限に活用するには、次のいずれかを使用してテストを作成することをお勧めします:
アプリケーション: アプリケーションを使用して新しいテストケースを記録します。
ナレッジベース: Web パネルの定義に基づいて UI テストの概要を自動生成します。

理由

参考記事