こんにちは、アピリオ北嵐です。第7回目となる今回は API 開発におけるテストについて考えていきたいと思います。API は定義されたインターフェースに従って動作するアプリケーションであり、ユーザーインターフェースとなる画面を持たない形式で提供されます。また Mule API の場合、API の実行基盤は MuleSoft が提供するクラウド/オンプレ環境で稼働するインテグレーションプラットフォームであり、ユーザーが開発するのは API の実装部分だけです。Mule API の開発を始めた多くのエンジニアは、”API はどのようにテストして品質を確保したら良いのだろうか？”という疑問を持たれると思います。
ソフトウェア開発におけるテストは、実装したプログラムを効率的に検証して目的とする品質を達成するために、様々なフェーズ、テスト手法、テスト種別、テストツールを使って行われます。API に対するテストも長年に渡って積み重ねられてきたテスト体系をベースを考えていくのが正しいアプローチだと考えますので、まずは従来のシステム開発におけるテストについて振り返ることから始めたいと思います。
システム開発における3種類のテスト
システムに対するテストは、一般的に次の3つのレベルに大きく分けられます。本番稼働するシステムであれば、何らかの形でこれら3つのレベルのテストを順に実施しながら、品質を積み上げていくものです。
上記の 3 つのレベルのテストを Mule API 開発にどのように適用できるでしょうか。考え方は色々あると思いますが、各レベルで検証すべき品質と Mule API の特長を考慮して、アピリオでは以下のように各テストの内容を考えています。
単体テスト（UT）
以下に Anypoint Studio で開発する典型的な Mule アプリケーションの構成を示します。API インターフェース部分は RAML 形式の I/F 定義から自動生成されるフローで、API 実装の部分が手作業で実装するフローになります。
[Mule アプリケーションの構成]
Mule フローの単体テストツールとしては MUnit が提供されていますので、単体テストの実装は MUnit を使用してローカル環境の Anypoint Studio 上で実施することにします。また、自動生成されるフローに対する単体テストは、かける工数に対して得られる品質上のメリットが小さいため、単体テストは手作業で実施する API 実装部分のフローに対してのみ実施します。外部リソースへの呼出しは MUnit の Mock 機能を使用して Mock 化することで、実際の外部リソースには接続しません。
Mule プラットフォーム上で稼働する API 全体の処理で考えますと、以下に示す部分が単体テスト（UT）の検証範囲になります。ホワイトボックス観点からの MUnit によるフロー定義の検証と DataWeave スクリプトの検証が主になります。
[UT のカバー範囲]
結合テスト（IT）
単体テストではホワイトボックスの観点からフロー定義（組み合わされたコンポーネント）を検証しました。結合テストでは、Mule API を構成する下記の 3 つの要素を結合させた状態で、API 全体の機能を I/F 定義の観点から検証します。
- API インターフェース
- API 実装
- ポリシー定義
単体テストでは Mock だった外部リソースへの呼出しは本物を呼び出します。ローカル環境ではなくCloudHub サーバー上に API をデプロイしてからサーバー上でテストを実施します（サーバー環境は本番ではなく Sandbox 環境を使用）。
単体テストでホワイトボックス観点から検証した機能は、結合テストでは詳細なバリエーションでテストする必要はないため、API 実装フローはブラックボックスとして扱い、テストケースのケース作成ではコンポーネント実装は考慮しません。
テストは通常のテストと同じように Excel 等の Office ツールでテストケースを作成し、手作業で実施します。ケースは対象 API の I/F 定義を元に正常系/異常系の観点から作成します。API の実行にはツール Advanced Rest Client を利用すると良いでしょう。
以下に IT の検証範囲を示します。
[IT のカバー範囲]
下記の表は UT と IT の検証内容を作業別に整理したものです。参考にしてください。
システムテスト（ST）
ここまで、Mule API に対する単体テスト（UT）と結合テスト（IT）の内容をご紹介してきましたが、システムテストでは何を検証すべきでしょうか？ エンタープライズ系のシステムであれば、結合テストではサブシステム内結合、システムテストではシステム全体を結合といった具合に結合度を変えたテストをシステムテストで行います。また、画面系のシステムであれば、機能の観点ではなく業務（ユースケース）の観点からのテストケースを準備してシステムテストで実施することがあります。Mule API のケースではいずれも当てはまらないため、こうした観点のテストはシステムテストには含まれません。
機能観点のテストは結合テストで完了していると考え、機能以外のテスト、つまり非機能に関するテストをシステムテストで実施することが次に考えられます。Mule API に関する非機能要件のテストとしては下記のようなものが挙げられます。
- 性能・負荷テスト
※ 対象APIに対する想定Trx数をベースにMuleアプリケーションの設計・実装が行われていることが前提 - 運用系機能の検証（アラート、カスタムレポート出力、ログアーカイブ）
- API の本番リリース作業の確認
- Mule ランタイムのバージョンアップ作業
また、VPC（Virtual Private Cloud: CloudHub内に独立した Private なネットワークセグメントを準備するオプション）を使う組織では、カスタムドメインなどのネットワーク設定の検証も結合テストではなくシステムテストとして実施することになるでしょう。
このように非機能の観点から、APIが本番での運用に耐えうる品質を持っているかを様々な角度から検証していくのが Mule 開発におけるシステムテストになると考えます。
おまけ：チェックリストの準備
Mule API に対する UT および IT では、テスト内容はかなり定型化されると考えます。そのため、品質および作業効率の観点からは、事前にチェックリストを準備しておくことをお勧めします。チェックリストは開発者間での差異を最小限にして、必要なテストを確実に行わせるための有効な手段だと思います。
[IT チェックリストの例]
今回は、Mule API 開発におけるテストの考え方について、アピリオでの事例を紹介しました。単に動くだけのサンプルアプリを作るだけであれば、簡易的な検証で十分でしょうが、本番運用に耐えうる堅牢な API を開発するためには、一般的なシステム開発と同じように単体テスト、結合テスト、システムテストの 3 つのレベルの検証を実施すべきと考えます。もちろん、Mule を適用する組織や機能によって必要とされる品質は異なってくるものですので、どのテストをどこまで実施すべきかはケースバイケースになるでしょう。例えば、MUnit による自動化されたテストケースを開発するにはそれなりのコストがかかりますので、数多く再利用される System API では MUnit によるテストを実施しますが、下位の API を組み合わせて提供される Experience API では最小限のテストのみを実施するといった考え方もできます。またシステムテストにおける運用系のテストも、必ずしも全てのAPIに対して必要なものではないでしょう。
一般的に開発のスピード感と品質は反比例するものです。Mule API の開発はできるだけ既存の API を再利用して迅速に行っていくことが 1 つの目標になりますので、これを達成するためには杓子定規にプロセスで定められたテストを実施するというウォーターフォール的な考え方ではなく、開発する API に対するビジネス的な優先順位を考慮した上で必要なテストを実施していく、臨機応変なアジャイル的なアプローチも大事ではないでしょうか。
次回は API Manager を使ってAPIに対して定義するポリシーと SLA をご紹介します。
[MuleSoft 入門シリーズ]
MuleSoft 入門（1）MuleSoft による API-led なアプリケーションネットワーク
MuleSoft 入門（2）ようこそ Anypoint Platform へ
MuleSoft 入門（3）Anypoint Studio による API の実装
MuleSoft 入門（4）DataWeave によるデータ変換
MuleSoft 入門（5）Flow Designer で Mule アプリケーションを開発
MuleSoft 入門（6）MUnit による単体テスト
MuleSoft 入門（7）API 開発におけるテストの考え方
MuleSoft 入門（8）ポリシーと SLA
MuleSoft 入門（9）カスタムポリシーの開発
MuleSoft 入門（10）Mule API のバージョン管理
MuleSoft 入門（11）ランタイムログの自動アーカイブ
著者について
Naoki Kitaarashi のコンテンツをもっと見る
