GitLab CIパイプラインでテスト管理を統合する方法

この記事はMatthew Heusserによるゲスト投稿です。

この記事では、既存のJUnit との統合マニュアルを基に、Java のサンプルを使用して、CI/CD (継続的インテグレーションおよび継続的デリバリー) パイプラインの一環としてテストを実行する方法を説明します。Gitlab のサンプルを使用して、「なぜ」、「何を」行うかについて説明します。

テスト管理と CI/CD を統合する理由
テストケース管理システムとCI/CDパイプラインの統合
TestRailとGitLabの統合方法
よくある統合シナリオ
関連する製品
- テスト管理ツール TestRail
  - ■ TestRailの特長 ■
- テストの生産性向上をTestRailでお試しください

テスト管理と CI/CD を統合する理由

継続的インテグレーション (CI) には、「自動化されたビルド」あるいは「 (おそらくは『部分的』に)自動化されたテスト」よりはるかに多くの利点があります。バージョン管理システム内のすべての変更に対してビルドを実行することで、CI はビルドを壊したりテストを失敗させたりする変更を正確に追跡できます。つまり、エラーを発生させたコード行、変更を行ったメンバー、時間を突きとめ、さらには変更が実現する予定だった機能、ストーリー、ビジネス機能までさかのぼることができる場合もあります。Framework for Integrated Tests(Fitnesse)に関する仕事で知られるIndustrial LogicのコンサルタントBrett Schuchertは、ここで違いを生むのが小さなコミットであると主張しています。私たちの経験では、1度に追跡する変更が1つだけの場合、デバッグおよび修正の時間を25-90%削減できます。 Schuchertにこの数字を示したところ、返答は「この情報があることで、そうでなければ解決不可能だった問題が解決可能になるのだから、実際の効果はそれよりずっと高いだろう」というものでした。小さな変更は継続的デリバリー、つまりCI/CDの「CD」をも可能にします。

単純なコンパイルの問題以上のエラーを見つけるには、継続的インテグレーション（CI）システムである程度の自動化されたテストを実行する必要があります。それは単体テストかもしれませんし、APIテスト、フロントエンドの JavaScriptテスト、あるいはSeleniumなどのツールを使用したエンドツーエンドテストかもしれません。一部の企業、特にソフトウェア分野のスタートアップ企業は、この種の自動化されたテストだけを実行しています。いっぽう、レガシーソフトウェアを抱える多くの企業は、ツールの結果と人間による探索を組み合わせたハイブリッド方式を採用しています。

ここで、稼働中のシステムの品質について考えてみましょう。マネージャーや重役は、ソフトウェアの次期リリースや、変更点や、最新のビルドに関する情報をどこで得たらよいのでしょうか？CI/CDの結果はきわめて技術的であり、ツールが自動的に実行できるものに限られています。TestRailなどのテストケース管理システムは結果の単一のビューを提供できますが、それは結果が統合されている場合だけです。つまり、テスト実行に伴って人間がテストケースを更新するとともに、CI/CD実行時に何かがテストケース管理システムを更新する必要があります。そこで、テストケース管理システムが公開しているAPIを使用して、CIシステムにテストケース管理システムを更新させようというのが、今回の記事の趣旨です。

そのように変更すると、CI/CDは次のセクションの図のようになります。

テストケース管理システムとCI/CDパイプラインの統合

まず、変更を行います。たとえば、私たちが使用する三角形の問題をテストするサンプルでは、より大きな整数型を取るようにコードを変更することが考えられます。境界がより大きな数値に変更されたため、この変更は境界エラーをチェックするテストが失敗する原因になります。プログラマーは自分がテストしているオブジェクトに関連する単体テストは実行するかもしれませんが、テストスイート全体やより高いレベルでのテストは行わないでしょう。変更は新たな期待値を導入するため、ソフトウェアがそれらの期待値を満たしていないために他のテストが「失敗」したり、他の機能が壊れたりすることがよくあります。たとえば、APIの結果の構造を根本的に変えてしまうようなAPIの変更は、フロントエンドのJavaScriptの問題を引き起こす場合があるでしょう。下の図は、CI/CDパイプラインの全体像を示しています。

出典: Learn.Gitlab.com

小さい長方形-CIパイプライン-が今回の焦点です。ここでテストの失敗（または成功）が発生します。CIパイプラインを実行すると、「成功ビルド」ができ、おそらくはパッケージが生成されます。継続的デリバリーパイプラインが成功すると、何らかの最終チェックを行うためのチケットが作成され、チェックに合格すると、意思決定者がコードを運用環境に「プッシュ」できるようになります。継続的デプロイメントパイプラインは、パイプラインが成功したら、運用環境へのプッシュを行います。失敗時にはすべてのシステムが後戻りし、停止し、失敗の原因になったユーザーや関係するマネージャーに通知を送信します。

成功および失敗を返す方法はいくつかあります。結果を記述したテキストファイル、テストアプリケーションからの終了コード、あるいはSTDOUTに送られたリダイレクトまたはキャプチャ可能なテキストです。CIパイプラインはこれらの結果を取得して「レッド」（失敗）または「グリーン」（すべて合格）を表示します。本質的には、CIツールはコマンドライン実行の組み合わせ、if-then文、設定、結果のダッシュボード表示の非常に複雑な集合であるとみなすことができます。CIツールにコードの場所を指定し、ビルドを実行したり結果を解釈したりする方法を指示し、グラフを参照します。極端に単純化した説明ですが、テスト管理システムを更新する方法をつかむのにはじゅうぶんです。簡単なプログラムを作成して新しいテストランを作成し、テストケースごとに、該当テストランでテストケースが成功したか失敗したかを更新します。結果を追跡し、成功または失敗を指定してテストランをクローズします。

この後、やり方を説明していきます。

TestRailとGitLabの統合方法

このサンプルは、GitHubの実際のプロジェクトから始め、ローカルにインストールされたGitおよびソフトウェアをビルドするワーカーとして動作するローカルマシンのGitLabランナーを使用します。このチュートリアルでは、パイプラインを作成する詳しい手順を説明します。

まず、GitHubアカウントを作成し、フォークします。JavaSamplesリポジトリがよいサンプルになります。著者が実行すると、新しいURLhttps://github.com/heusserm/hellogitworldが取得されました。ドロップダウンでコードをクリックしてローカルマシンにコピーし、コードディレクトに移動して、コマンドラインから次のコマンドの “heusserm” を自分のユーザー名に置き換えて実行します。

git clone git@github.com:heusserm/JavaSamples.git

今度はGitLabのホーム画面で[New Project]>[Run CI/CD for an external repository]を選択し、[Connect repositories from GitHub]をクリックするか自分のGitリポジトリのURLを貼り付けます。

GitLabのランナーをインストールします（Windows、Linux、Mac OS用インストーラー）。ランナーを登録する必要があります。GitLabの[Project Settings]>[CI/CD]>[Runners]で登録コードを取得します。これによってランナーをGitLabに接続します。ローカルマシンからの実行は最も簡単で最も安全性/安定性の低い方法ですが、環境は完全にセットアップされ、コンパイルは正常に実行されます。

次の画面ショットは登録プロセスを示しています。

ランナーを登録したら、[Project Settings]>[CI/CD]>[Runners]に戻り、[run untagged jobs]をオンにして変更を保存します。こうすると、このランナーがすべてのジョブのデフォルトのランナーになります。

以前のバージョンでは、TestRailのユーザー名とパスワードはソースコードに書かれていました。このバージョンはGitHubで公開されているため、TestRail_USERNAMEおよびTestRail_PASSWORD環境変数からユーザー名とパスワードを取得するようコードを変更しました。それ以外は、TestRail APIを呼び出すJavaサンプルを含むJUnitとTestRailの統合マニュアルのコードと同じです。GitLabを動かす設定ファイルは .gitlab-ci.yml という名前です。このサンプルを動作させるために、ビルド、テスト、レポートを個別のコマンドに分割しました。また、テストが失敗したときにOSにエラーコードを送信するコードをレポートプログラムに追加しました。こうすると、何かが失敗したとき、失敗がレポートされます。

GitLabにビルド、テスト、レポートの方法を指示するgitlab-ci.ymlファイルは次のとおりです。

stages:
  – buildtestreport
build-job:
  stage: buildtestreport
  script:
    – cd TestRail_triangle/Triangle_02/
    – ./01build.sh
    – ./02test.sh
    – ./03report.sh

Macでは、ファイアウォール越しにGitLabでランナーを動作させるために、brew、git-lfs、gitのバージョンをアップグレードする必要がありました。これが完了したら、JavaSampleでコミットが行われるたびにランナーがキックオフされ、CIパイプラインが実行されます。典型的なGitLabパイプラインはこのサンプルと非常によく似ていますが、ジョブの分割とファイルを成果物として渡すことだけが異なります。

Java ファイルを編集して変更をGitLabにコミットすると、新しくパイプラインの実行がキックオフされます。

特定のパイプラインをクリックしてランのすべてのテキスト出力を参照します。

また、パイプラインを変更したことで TestRail も更新されます。

よくある統合シナリオ

上記のサンプルは、TestRailのテストケースとテストフレームワークのテストケースをマッピングします。実行するたびに「テストラン」が作成され、クローズされます。しかし、これが唯一の方法ではありません。別のアプローチとしては、テストスイートの1つのテストケース毎にテストランを作成します。たとえばAPI用のテストランおよびエンドツーエンドテスト用のテストランです。もう1つカテゴリとして一般的なものは単体テストです。個々の単体テストをテストケースとして追加するのは一般的なやり方ではありません。ただし、TestRailとCI/CDの統合では、単体テストの主要なグループごとに1つのテストケースを追加し、単体テストを可視化するのは比較的容易です。

もっと複雑なCI/CDパイプラインを持ち、あらゆる変更に対してすべてのテストを実行した後に、変更をまとめてリリース候補として先頭またはメインブランチにマージする企業もあります。そういった「リリース候補」のビルドに対してだけテストランを作成するようパイプラインを設定することもできます。また、他のテストを実行しているメンバーが手動でテストケースを更新する必要があるため、テストランを作成した後にクローズしないことが適切な場合もあるでしょう。

もう１つのアプローチは、オープン中のテストランを１つ作成し、何らかの種類の設定ファイルとしてCIに保管するという方法です。CIは新しいランをオープンせず、既存のランのテストケースを更新します。デプロイメントが発生すると、デプロイメントを行うソフトウェアは新しいテストランを開き、設定ファイルを更新します。

何が「正しい」選択かは、組織にとって何が適切かによって異なります。TestRailの機能へはAPIでアクセスできるため、コンピューターは人間と同等の操作を実行できます。コンピューターが作業結果を統合し、ソフトウェア品質に対する単一の統合されたビューを実現することが可能です。これこそ、重役たちが長年にわたって要求してきたものです。

要求に応えようではありませんか。ソフトウェアのビルドとテストを行い、テストランを自動作成してTestRailのテストケースを更新するサンプルプログラムについては、TestRailとJUnitの統合に関するドキュメントを参照してください。

Matthew Heusser はプロジェクト管理、開発、著述、システム改善の知識を持ち、Excelon Development の Managing Director を務めています。そしてもちろん、ソフトウェアテストも行っています。

（この記事は、開発元Gurock社の Blog 「How to Integrate Test Management in Your GitLab CI Pipelines」2022年5月16日の翻訳記事です。）