Azure FunctionsのHttpTrigger関数を単体テストの構成を考える

1. 記事の範囲

背景・要件を考慮した、単体自動テスト導入のための「技術選定」「構成」を考える。

2. 背景

Azure Functionsを利用したAPIがある。APIは.NET 6, C#で実装されている。自動テストを導入していないため、開発者としてテストのコスト軽減を図りたい。最初に機能テストの自動化から行うための、技術選定を実施したい。プログラミング言語やCI/CDシステムは極力サービスで使用されているものを利用し、学習コストは抑えたい。またテストケースはコード上で見える化され、属人化せず開発者がメンテナンス可能である事で、継続コストを抑える事を達成したい。

3. 要件

下記の要件を満たした下記の技術と構成を検討する。
・API単体でテストが実施され、UIテストや受入れテストと切り離して行われる。
・Azure FunctionsのHttpTrigger関数を単体テストが実施できる。
・継続的な統合/継続的なデプロイメント（CI / CD）パイプラインの一部として使用できる。

4. 内容

構成

プログラミング言語やCI/CDシステムは現状使用されている技術と同様のもので構成する。C#で開発されている事からテストコードは「xUnit, Moq 」のフレームワークを用いる。また CI / CDは「Github Actions」を利用する。
Azure FunctionsのHttpTrigger関数を単体テストの実施に関しては、xUnitはテストケースごとに、テストクラスがインスタンス化されるのでAPI単体でテスト実施可能である。またUnitテストを目的としたフレームワークのため、他レベルのテストに依存しない。 その為API単体でテストが実施され、UIテストや受入れテストと切り離して行える。

下記の項目で自動テストができるように構成する。

項目	詳細
テストフレームワーク	xUnit, Moq
実行方法	開発環境で実行。 各Pull Requestのコード更新時の自動実行。
実行単位	開発環境のコンソールでのみ個別テスト実行。その他はAPI (Azure FunctionsのHttpTrigger関数) 単位で実行。
結果の確認	パイプラインでの実行結果はPull Request上, GitHub Actionsで確認。
管理方法	GitHubリポジトリ内でサービスコードと同様に管理
CI / CD	Github Actions

テストスコープ

テストスコープは導入するプロジェクトによって異なるので、今回の要件範囲を整理する。この記事では、単体テストを構成するにあたり、単体とは「1つのクラスまたは同じ目的を達成するためのクラスグループ」と考える。

	テストの目的	テストレベル
ユニットテスト	機能部品のモジュール、コンポーネントまでの範囲で、意図通りに実装ができているか、出力結果に意図しない変化がないか。	単体テスト / 結合テスト
APIテスト	APIが仕様通りに実装できていること。パフォーマンスやセキュリティに問題がないか確認。	単体テスト / 結合テスト
E2Eテスト	要件のデバイス(ブラウザ,モバイル)で動作すること。想定されるユーザーの操作シナリオや基本的な機能が実現できること。	システムテスト / 受入テスト

CI/CD

不具合が検出され実装の手戻りが発生しないように、CI/CDで自動テストを導入する。
PRを別のブランチにマージするには「ユニットテスト」と「レビュー承認」のステップを必ず踏む。これは「機能部品において期待されている結果を、実装者の意図通りにコードが実現できている」コードのみ、主要なブランチにマージされることを目的とする。

今回は統合テストを含めた構成ではないが全体のテストをCI/CDに含めることで、副作用を確認しないままこれは、Hotfixなど緊急修正のリリース時に予期しない副作用を防ぐ効果が期待される。

5. まとめ

Azure FunctionsのHttpTrigger関数を単体テストを作成するにあたり、テストフレームワークに「xUnit, Moq」を用いる。また「Github Actions」を利用しCI/CDに組込む事で自動テストを実施する。