スタブやモックサーバーでAPIを利用するテストをブーストしよう!
APIを利用するテストで使うスタブ、モックサーバー、そしてサービス仮想化についてご紹介する記事です。
はじめに
昨今、DXの実現を目指し、システムのモダナイゼーションやマイクロサービス化が広まりつつあります。それらは、APIでサービス/システム間を連携する特徴があるため、アーキテクチャ上の依存関係を考慮したテスト計画が必要になります。そのため、APIを利用するアプリケーションのテストでは、本物のAPIに接続できない時の代わりに、スタブ(Stub)、モックサーバー(Mock Server)、サービス仮想化(Service Virtualization)を活用したテストが重要になります。本記事ではそれぞれの役割や特性についてご紹介します。本記事は次のような方におすすめです。
- APIを利用するアプリケーションの開発案件やテスト計画に関わる/関わっている方
- API を開発している他チームや他社との調整が必要となり、即座に API に接続してテストできない課題がある方
- 他社が提供するテスト環境の貸し出しが 17:00 までとなっている等で、API に接続してテスト可能な時間が制限される方
- API 側の開発が遅延している、または、API 側になんらかの問題が発生していて接続できない課題がある方
本ページの目次 |
関連記事:APIを利用するアプリケーションのテスト戦略についても閲覧をおすすめします。
スタブとモックサーバーの役割
スタブとモックサーバーはいずれも、APIを利用するアプリケーションのテストにおいて、連携先のAPIが未実装などで自由に利用できない場合に、本物のAPIに成り代わってテストに必要な振る舞いを行う疑似環境を指します。一般的には、APIを利用するアプリケーションのテストでは、目的に応じてスタブやモックサーバーなどの疑似環境を使用します。スタブ:必要最低限の決まったレスポンスを返すものとして利用
スタブとは、サービス/システム間連携を伴うテストにおいて、APIを利用するアプリケーションが連携するAPI(呼出し先)が未完成の場合や、なんらかの理由でAPIが利用できない場合にAPI(下位モジュール)の代用品として利用されます。主に、テスト対象アプリの動作確認を行うために使います。テスト対象アプリ(UIアプリなど)からの呼び出しに対し、あらかじめ設定している必要最低限の決まった値を返します。
上の図の例では、①テスト対象アプリで「java」と検索すると、②連携先のバックエンドにリクエスト電文が送信され、③バックエンドからレスポンス電文を受信します。このデータ連携により、④テスト対象アプリの画面上に検索結果が表示されます。この時、連携先のAPIが未実装であるなどの要因で利用できない場合に、スタブを使用します。UIテスト時にスタブを使用すると、画面に表示される内容や画面遷移が適切であるかを、いつでも、なんどでも検証できるようになります。
モックサーバー:期待通りのリクエストが送信されているか検証するためにも利用
モックサーバー(またはモック)はスタブの機能や特性に加えて、テスト対象アプリが正しくリクエストを送信しているかといったことも検証します。そのため、モックサーバーは、システム間連携を伴うテストにおいて、APIを利用するアプリケーションと連携先のAPI(呼出し先)が期待通りに連携しているか、どのように相互作用するのかを検証するために使われます。
上の図では、テスト対象アプリと、連携先となるAPIの相互作用を検証するためにモックサーバーが使用されています。 たとえば、①「java」というキーワードで検索した時に②「テスト対象アプリが送信するリクエスト電文が正しいか?」をモックサーバー側で検証します。また、③リクエスト電文に対し、モックサーバーから適切なレスポンス電文を返すことで、テスト対象アプリと連携先APIとの一連の振る舞いが想定通りに行われるかを検証することができます。
Martin FowlerのMocks Aren't Stubsでは、 モックサーバーはリクエストの検証も想定するものであることから、振る舞いの検証(Behavior verification)を目的として使用するとされていますが、一般的には、リクエストの検証は主に単体テスト(ホワイトボックステスト)のフェーズで実施される傾向にあります。また、機能テスト(ブラックボックステスト)におけるモックサーバーの用途は、スタブとは厳密な違いがなく、「APIを利用するアプリケーションをテストするために、予め決めた値をレスポンスする用途で使われるもの」であり、モックサーバーという言葉を使っていてもスタブのことを意味している場合が一般的です。
Martin FowlerのMocks Aren't Stubsでは、 モックサーバーはリクエストの検証も想定するものであることから、振る舞いの検証(Behavior verification)を目的として使用するとされていますが、一般的には、リクエストの検証は主に単体テスト(ホワイトボックステスト)のフェーズで実施される傾向にあります。また、機能テスト(ブラックボックステスト)におけるモックサーバーの用途は、スタブとは厳密な違いがなく、「APIを利用するアプリケーションをテストするために、予め決めた値をレスポンスする用途で使われるもの」であり、モックサーバーという言葉を使っていてもスタブのことを意味している場合が一般的です。
スタブやモックサーバーが必要となる場面
API連携を行うアプリケーションの開発やテストにおいては、外的要因で開発やテストが中断するといった課題(デメリット)が発生することを前提としたテスト戦略が必要になります。テストが遅延すると、リリーススケジュール全体にも支障をきたすことにも繋がりかねません。APIが利用できず、テストが中断してしまう原因としては、以下のような例が挙げられます。
※以下のような場面で、スタブやモックサーバーが必要となります。
- バックエンドチームのAPI開発が遅延していてAPI連携できない
- 他のチームが共通のAPIを利用しているために、テストが終了するまで待たなければならない
- 外部のAPIとの連携が必須だが、API を利用できる時間に制限がありテストを自由にできない
そのため、API連携を伴うアプリケーション開発においては、スタブやモックサーバーを用いていつでもテストが可能な環境を構築する必要があります。
スタブやモックサーバーは開発 / メンテナンスに工数が掛かる
一方で、多様なリクエストに対して適したレスポンスを返すようにスタブやモックサーバーを作成するためには、プログラミングでif文やcase文を多用し、レスポンス条件を詳細に記述する必要があります。そのため、必然的に複雑なコーディングを行うことになります。また、一般的には開発時にスタブの設計書を作ることはないため、複雑なレスポンス条件の妥当性を理解したり、運用する際のメンテナンスが非常に大変になります。
そのため、スタブやモックサーバーを利用する場合、以下のような課題がよく挙げられます。
- スタブやモックサーバーの開発に工数が掛けられず、固定のレスポンス値を返すだけになってしまいテストのバリエーションが不十分
- バリエーション豊富なテストを可能にするスタブやモックサーバーの作成・メンテナンスに工数が掛かる
- スタブやモックサーバーの開発ではなく、そもそも本来の開発やテストに工数を割り当てたい
開発 / メンテナンスを効率的に実施する方法
前項でご紹介したように、スタブやモックサーバーでは開発やメンテナンスに手間が掛かることが大きな課題としてよく挙げられますが、これらの課題を解決するソリューションとしてサービス仮想化(Service Virtualization)があります。サービス仮想化では、スタブやモックサーバーと同様にAPIを利用するアプリケーションのテストで利用するものですが、より強化された機能を備えており、疑似環境の作成やメンテナンスについても効率的に行うことが可能です。下の図は、サービス仮想化をフロントエンドのテストで利用するイメージとなりますが、スタブやモックサーバーと同様にバックエンドのAPIをテストする時の疑似環境(バックエンドのAPIから呼出す他サービス/他システムのAPIを仮想化する用途)としても利用されます。
サービス仮想化とスタブやモックサーバーの違い
では、具体的にスタブやモックサーバーとの違いはどこにあるのでしょうか?ここからは、テストの効率をさらにブーストするサービス仮想化について、スタブやモックサーバーとの主な違いをご紹介します。比較観点 | スタブやモックサーバー | サービス仮想化 |
---|---|---|
テスト環境の作成方法 | コーディングで作成 | コーディングが不要で、IF定義ファイル (APIの設計書)やAPIトラフィックの キャプチャから自動生成可能 |
対応するテスト範囲 | 必要最低限の決まった値で 応答することが一般的 |
ExcelやCSVに用意したデータを使用して 豊富なバリエーションで応答 |
メンテナンス性 | 複雑なコードになる場合が多く メンテナンスが困難 |
GUI上で直感的に操作でき メンテナンスが容易 |
資産やテスト方式の 共通化 |
場当たり的に作成することが多く 野良スタブ、野良モックサーバー になりがち |
共通のGUIで疑似環境を構築できる点に加え、 各メンバーが作成した資産の共有や再利用が 容易に可能 |
パフォーマンス・ 負荷テスト |
高負荷が掛かった際に落ちたり 性能が出ない場合がある |
高負荷時にも高スループットで処理できる 疑似環境を構築 |
上記のように、サービス仮想化は高性能なスタブ・モックサーバーでありながら、開発やメンテナンスに工数が掛からないといった大きな特長があります。
そのため、サービス仮想化をを採用することで、より効率的に開発やテストを実施することが可能です。
そのため、サービス仮想化をを採用することで、より効率的に開発やテストを実施することが可能です。
スタブやモックサーバーを自動生成!Parasoft Virtualizeのご紹介
前項でご紹介したサービス仮想化で疑似環境を構築し、開発/メンテナンスを効率的に実施するツールとして、APIテスト自動化/サービス仮想化ツール「Parasoft SOAtest/Virtualize」があります。このツールは、「開発 / メンテナンスを効率的に実施する方法」でご紹介した特長を含め、さまざまな便利な機能を備えたツールです。
Parasoft SOAtest/Virtualizeに関する詳細は、以下のページをご参照ください。
高性能なスタブを作るサービス仮想化ツール「Virtualize」
動画で紹介!サービス仮想化ツール
「Parasoft SOAtest/Virtualize」を使用した、サービス仮想化環境の構築手順を動画と共にご紹介しています。
高性能なスタブを作るサービス仮想化ツール「Virtualize」
動画で紹介!サービス仮想化ツール
「Parasoft SOAtest/Virtualize」を使用した、サービス仮想化環境の構築手順を動画と共にご紹介しています。
まとめ
この記事では、APIを利用するアプリケーションのテストで活用される、スタブ(Stub)、モックサーバー(Mock Server)、サービス仮想化(Service Virtualization)の役割や特性、さらにParasoft Virtualizeについて簡単にご紹介しました。APIを利用するアプリケーションのテストにおいては、これらの疑似環境を用意することでより早い段階からテストが実施できるため、テストを効率化し、シフトレフトを実現することが可能となります。テストをさらにブーストする手段として、サービス仮想化の活用を是非ご検討ください。
PICK UP
イベント・セミナー
APIのテスト自動化とサービス仮想化を1ツールで SOAtest/Virtualizeに
関するお問い合わせ
テクマトリックス株式会社
東京本社ソフトウェアエンジニアリング事業部
03-4405-7853
- メールでのお問い合わせ
- parasoft-info@techmatrix.co.jp