要約
以下内容について記載します。
- プログラムのテストとPytestについて
- pytest-htmlのプラグインについて
- GitHub ActionsとGitHub Pagesを使用してpytest-htmlで生成されたレポートを公開する方法について
はじめに
プログラムのテストでは以下の分類があります。
- 単体テスト（UT：Unit Test）
- 結合テスト（IT：Integration Test）
- 機能テスト（FT：Functional Test）
- End-to-Endテスト(E2E Test)
- 受け入れテスト(AT：Acceptance Test）
- システムテスト（ST：System Test）
これらは一般的にプログラミングにおいて共通しています。そしてPython ではUT/IT(一部)をテストフレームワークであるPytestを使用することでテストできます。
また、テストはアーキテクチャ、モジュール、関数、メソッドによってテスト設計対象は異なります。
一般的に、UTでは関数、メソッドについて、原則としてすべてのロジックパスを一度は通るようなテストケースを作成し、検証すること（網羅率：100%）が必要ですが、FTはITの分類の一つであり、目的に応じてテスト設計が必要という認識です。
これらの解釈については下記の記事(Integration and Functional Tests)が参考になりますので共有させていただきます。
また、pytestでは拡張機能としてプラグインも開発されています。
一例は下記の通りです。
- pytest-cov: コードのカバレッジを計測し、レポートを生成する。
- pytest-html: テスト結果をHTML形式で出力し、視覚的なレポートを生成する。
- pytest-xdist: テストを並列で実行し、処理時間を短縮する。
- pytest-mock: テスト中にモックを簡単に作成し、モックオブジェクトを利用できる。
この中でテスト結果の確認ではpytest-htmlが有用です。コードと合わせてコミットすることでテスト結果をファイルとして管理/確認することができます。
他にも、カバレッジ率の確認ついては下記記事が参考になりますので、共有させていただきます。実際に私も使用しています。
pytest-htmlについて、レポート作成は有用ではあるのですが、
それはブラウザでHTMLを表示できるためです。
この点について、例えば、GitHubではコミットされたHTMLはブラウザ表示には対応していません。（あくまでコード管理のみ）
これではHTMLを生成しても視覚的に確認できなければプラグインを十分に活用できているとは言えません。
そこで、実現方法について調べたところ、GitHub Pape1を使用することでウェブサイトとして表示できることがわかりました。
前置きが長くなりましたが、本記事では調査した内容を元に、
GitHub ActionsとGitHub Pagesを使用してpytest-htmlで生成されたレポートを公開する方法をまとめたので、紹介します。
作成したもの
コードは四則演算をするシンプルなものですが、これをpytest-htmlを使用してテスト結果のレポートをHTMLで作成し、GitHub Papesへのデプロイします。
これらの処理はワークフローとして作成して実行します。
注意事項として、下記リポジトリは実験用のもので非定期に更新しますので、使用/参照する際はご注意ください。
実例については、別プロジェクトのvideo-grid-mergeのリポジトリを参照いただいた方が良いかと思いますが、本記事では以下のリポジトリ例で示します。
また、公開したレポートはREADME.mdからアクセスできるようにshieldsでバッジを作成してアクセスできるようにしています。
使い方と詳細
後述するワークフローファイルをコミットすることでテスト結果のHTMLを作成し、GitHub Papesへのデプロイをすることができます。しかし、使用するためにはいくつか設定が必要です。
まずは、GitHub Pages用にブランチを作る必要があります。
ワークフローではブランチ名はghpagesとします。そして、ghpagesブランチをデプロイ先のブランチに指定します。
ghpagesはブランチ元のコードが存在する場合は、.git以外を削除してコミットしてください。
ghpagesブランチをデプロイ先のブランチ指定する方法
次に、pagesから下記項目でデプロイ先のブランチ(ghpages)を指定します。
ghpagesへデプロイするためのGitHub Actionの設定
次に、以下のGitHub Action用のワークフローファイル(.yml)をmainブランチの.github/workflowsに格納してください。
以下の例ではOSとしてUbuntu,Mac,Windows(Server)で実行する例を示します。
ワークフローファイル
ジョブを実行方法として2例を示します。
osには、ubuntu-latest, macos-12, windows-latestを指定して実行します。
ワークフローでは以下のline-notifyのアクションを使用しています。不要であればコメントアウトしてください。
使用する場合は変数を作成して設定する必要がありますので、
Settings > Secrets に LINE Notify で取得したアクセストークンを LINE_ACCESS_TOKEN を設定してください。
jobs / needs指定による直列実行する例
jobsでジョブを作成し、それをneedsで指定すると、指定したジョブの完了を待って次のジョブを実行するように制御できます。詳細は下記を参照ください。
strategy / matrix指定による並列実行する例
strategy / matrixを指定することで、ジョブを変数の可能な組み合わせごとに実行するように制御できます。詳細は下記を参照ください。
実行結果
jobs / needs指定による直列実行の実行結果例は下記の通りです。
ワークフローでは、strategy / matrixで並列動作もできますが、needsで1jobずつ順番に実行したほうが良いと個人的には思います。
理由は、GitHub Actionsでは、デプロイ用のワークフローを設定しない場合、デフォルトの設定では、同じリポジトリに対して複数のデプロイが同時に行われると、一部のデプロイがキャンセルされることがあります。
これは、GitHubがリソースを効率的に管理し、最新のデプロイを優先するための仕組みのためのようです。
strategy / matrix指定による並列実行の実行結果例は下記の通りです。
上記workflow runsの状態を確認すると「！」マークが表示されていますが、中身を確認すると、エラー内容としてpages build and deployment@ghpagesの優先度の高い待ちリクエストが存在するため、キャンセルしますとあります。最新のデプロイを優先するためこのようなエラーが表示されているという理解です。
まとめ
GitHub ActionsとGitHub Pagesを使用してpytest-htmlで生成されたレポートを公開する方法として、
ワークフローは正直分岐が多く見づらい部分もありますが、HTMLの可視化はできているので興味があればフォークをして活用してもらえればと思います。
