MuleSoft入門(7)API開発におけるテストの考え方

December 19, 2019 Naoki Kitaarashi

こんにちは、アピリオ北嵐です。第7回目となる今回は API 開発におけるテストについて考えていきたいと思います。API は定義されたインターフェースに従って動作するアプリケーションであり、ユーザーインターフェースとなる画面を持たない形式で提供されます。また Mule API の場合、API の実行基盤は MuleSoft が提供するクラウド/オンプレ環境で稼働するインテグレーションプラットフォームであり、ユーザーが開発するのは API の実装部分だけです。Mule API の開発を始めた多くのエンジニアは、”API はどのようにテストして品質を確保したら良いのだろうか?”という疑問を持たれると思います。

ソフトウェア開発におけるテストは、実装したプログラムを効率的に検証して目的とする品質を達成するために、様々なフェーズ、テスト手法、テスト種別、テストツールを使って行われます。API に対するテストも長年に渡って積み重ねられてきたテスト体系をベースを考えていくのが正しいアプローチだと考えますので、まずは従来のシステム開発におけるテストについて振り返ることから始めたいと思います。

システム開発における3種類のテスト

システムに対するテストは、一般的に次の3つのレベルに大きく分けられます。本番稼働するシステムであれば、何らかの形でこれら3つのレベルのテストを順に実施しながら、品質を積み上げていくものです。

テストレベル
定義

単体テスト(UT)

プログラムを構成する最小単位で実行されるソフトウェアテスト。モジュールテストとも呼ばれる。

テストドライバやスタブを使用する。

結合テスト(IT)

システムやプログラムの結合段階で行われるソフトウェアテスト。システムを構成するモジュールやサブシステムが設計通りに相互連携するかを検証する。モジュール間のI/Fやデータの受け渡しをチェックする。

システムテスト (ST)

開発したシステムが定められた環境で期待通りに動作するかを検証する。実際の使用状況を想定して多角的に様々なテストを実施する

上記の 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 定義の観点から検証します。

単体テストでは 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

アピリオのシニアコンサルとしてクラウドの世界に身を投じてはや5年あまり。プロジェクトでの立場に応じて、アーキテクト、リーダー、デベロッパーと様々なロールの仕事に携わっています。続々と新しいサービスと技術が登場するSalesforceの世界はエンジニアとして常に刺激を持ち続けられるエリアであり、2019年からはMuleSoftソリューションの起ち上げに関わっています。しばらくはAPI-ledなシステム連携を広めることに全力投球!!

Naoki Kitaarashi のコンテンツをもっと見る
戻る
MuleSoft 入門(6)MUnit による単体テスト
MuleSoft 入門(6)MUnit による単体テスト

今回は Anypoint Studio で開発したMuleアプリケーションを JUnit ライクに単体テストできる MUnit をご紹介します。MUnit は Mule フロー定義の検証用に Anypoint St...

次へ
MuleSoft 入門(8)ポリシーと SLA
MuleSoft 入門(8)ポリシーと SLA

これまで API の実装開発とテストの手法に関して紹介してきましたが、 API は実装したらすぐに運用開始できるというものではありません。今回は、API のアクセス制限の要である API Manager の機能の中...

アピリオまでお気軽にお問合せください

ご質問はこちら