Mountebank：柔軟なWeb API非表示

最新のITシステムの開発に関して言えば、外部依存関係のハッキングの問題は常に近くのどこかにあります。 開発段階で外部サービスを利用できない場合や、その機能が並行して開発されており、信頼できない場合があります。 この質問は、システムの通常の動作だけでなく、外部サービスへのアクセス不能、外部サービスがエラーで応答する場合などの例外的なケースもチェックする必要があるため、自動テストの作成段階では特に深刻です。



運が良く、製品が外部サービスに最小限の依存関係を持っている場合でも、その内部はコンポーネント（ジャンルのバックエンド/フロントエンド）に分割されている可能性が高いため、個別にテストできます。 これは、外部依存関係が既に隣接コンポーネントのAPIであり、その開発チームがその状態を管理するツールを提供することをまったく望んでいないことを意味します。



私の観察によると、テストチームは自動テストの最も基本的なケースに限定し、外部システムの動作を再定義できないことを説明しています。



外部システムのAPIをモックすると、この問題を解決できます。



通常、この時点で、テスターは悲しみを感じ始めます。 前の文は、自動テスト自体に加えて、機能的に外部システムを複製するサービスを作成する必要があり、これに加えて、テストに応じて同じリクエストに異なるように応答できるように何らかの状態を管理する必要があることを意味しますケース。



この記事では、 Mountebankについて説明します。これは、独自のWebサービスを作成することなく、自動テストから直接、迅速かつ非常に柔軟にAPIをラップできるツールです。



Mountebankの機能：

• tcp、http、https、smtpプロトコルでAPIを非表示にします。
• 無制限の数のAPIを同時に濡らす。
• mountebankの構成APIを使用したテスト中のモックAPIロジックの柔軟な再定義。
• 外部サービスAPIへのリクエストのプロキシ、応答およびその後のモックAPIでの使用の可能性の保存。
• ほとんどのプログラミング言語（JS、Python、Ruby、Java、その他多数）のクライアントライブラリ。

コンセプト

mountebankの根底にある考え方はシンプルで独創的です：すべてのテストケースに対して1つのユニバーサルモックAPIを一度に記述する必要はありません。特定のテストケースが必要とする範囲まで各テストの前にモックAPIの動作を再定義する方が効率的です。



Mountebankは、テストサイトに展開され、独自のWeb APIを持つWebサービスです。 このAPI構成を呼び出します。 構成APIは、mock-APIに配置するロジックをmountebankに伝えるのに役立ちます。 その後、mountebankは偽装者、つまりモックAPIを実装するWebサービスを選択します。 同時に、mountebankは、詐欺師の行動を再定義する頻度を制限しません。



つまり、各テストの前に文字列を再定義し、特定のテストに必要なロジックを正確に記述することができます。 そしてこれ以上何もない！

設置と最初の湿式法

mountebankの知識は、インストールから始める必要があります。 これはnode.jsアプリケーションであるため、npmを使用してこれを行うのが最も論理的です（事前にインストールされたnode.jsが必要です）。

>npm install -g mountebank
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

node.jsを個別にインストールしたくない場合は、 プラットフォームごとに別の方法があります 。

次に、コンソールからmountebankを実行します。

 >mb
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

デフォルトでは、mountebankはポート2525を占有します。すべてが正常な場合は、挨拶が表示されます。







mountebank自体の構成APIがハングしているのは、localhost：2525です。



トレーニングするには、POST /テストメソッドを実装する単純な偽者を作成し、リクエスト本文にオブジェクトを含むJSONが含まれている場合

 { “message”: “ping” }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

次に、JSONを応答として送信する必要があります。

 { “message”: “pong” }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

それ以外の場合はすべて、400ステータス（不良リクエスト）を返します。



私たちはmountebankと通信し、 Postmanを通じて詐称します。



なりすましを作成するには、mountebank構成APIに次のリクエストを送信します。







詐欺師を作成するための要求が何で構成されているかについてのいくつかの言葉。



まず、詐欺師が動作するプロトコルと、傍受するポートを示します。 これは、モックAPIが上昇するポートになります。 次はスタブの配列です。特定の着信リクエストにどのように応答するかを詐称するためのルールです。



各ルールは、述語と応答で構成されます。

• 述語は、詐欺師がそれに応答するために着信リクエストが一致しなければならないパラメータを記述します
• 応答は、着信要求が述語と一致した場合に詐欺師によって送信される応答を記述します。

問い合わせが詐欺師に到着するたびに、リクエストへの準拠に関する独自のルールに従って実行されます。 要求がルールの述語を満たす場合、適切な応答が要求で生成され、ルールのさらなるバイパスが終了します。



詐欺師がどのように機能するかがわかったので、今度はそれをテストします。



最初のルールに一致するリクエストを詐欺師に送信します。







そして答えを得る：







次に、最初のルールに一致しないリクエストを送信してみましょう。つまり、2番目のルールに該当します。







応答として、400 Bad Requestを受け取ります。







すべてが機能します！



各詐欺師には、無制限の数のルールを含めることができます。つまり、さまざまな要求に対するかなり複雑な動作ロジックを組み込むことができます。



同時に、mountebankはさまざまなポートとプロトコルで同時に多くのimposter'ovを保持できるため、複数の外部APIを一度に濡らすことができます。

自動テストのアプリケーション

mountebankの仕組みが多かれ少なかれ明確になったので、ここで定められた概念が完全に明らかになった場所、つまり自動テストに適用してみましょう。



銀行のウェブサイト、ATMをカードに表示する機能をテストしているとします。 この機能を実装するために、frontはサーバーに要求を送信してATMの座標を取得し、応答を受信すると、それらをマップに表示します。



この機能のテストは、2つのシナリオを意味します。

• frontは有効な座標を持つATMのリストを受け取りました：それらがすべて地図上に正しく表示されると期待しています。
• frontはATMのリストを受け取りましたが、一部の座標は無効です。有効な座標を持つATMのみが表示されると予想されます。

どちらの場合でも、テストされたページは同じリクエストをバックエンドに送信します：GET / api / points。



APIバックエンドをロックせずに両方のケースを検証することは不可能です。両方のケースのバックエンドは、いずれのケースも満たさない同じポイントセットを返します。

特定のデータセットを提供する独自のサービスを作成した場合でも、1つのケースのみを自動的にチェックできます。



次に、mountebankを使用してこれらのテストケースを自動化する方法を見てみましょう。

デモンストレーションには、python + pytestバンドル （強力なフィクスチャサブシステムを備えたテストフレームワーク）を使用します。

 import pytest import requests import json from page_objects import MapPage #     valid_points = { "point_1": (55.999653, 37.206002), "point_2": (55.996767, 37.184545), "point_3": (55.984932, 37.208749), } #       invalid_points = { "point_1": (255.999653, 37.206002), "point_2": (55.996767, 237.184545), "point_3": (55.984932, 37.208749), } #   @pytest.fixture( scope='module', params=[valid_points, invalid_points], ids=['Valid points case', 'Invalid points case'] ) def fxtr_map(request): points = request.param #   imposter'a imposter_cfg = { "port": 1987, "protocol": "http", "stubs": [ { "predicates": [ { "equals": { "method": "GET", "path": "/api/points" } } ], "responses": [ { "is": { "statusCode": 200, "headers": {"Content-Type": "application/json"}, "body": points } } ] } ] } #   mountebank    imposter'a requests.request('POST', 'http://localhost:2525/imposters', data=json.dumps(imposter_cfg), headers={"content-type": "application/json"}) #      ( ) browser = webdriver.Chrome() browser.implicitly_wait(10) browser.get(MAP_PAGE_URL) map_page = MapPage(browser) #        points_to_check = {k: points[k] for k in points if points[k] == valid_points[k]} #       #     yield map_page, points_to_check browser.close() # ,   def test_points_on_map(fxtr_map): map_page, points_to_check = fxtr_map #           assert map_page.check_points(points_to_check)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

始めます。







出来上がり！



mountebankのおかげで、特定のポイントセットが得られるようにフィクスチャからモックAPIを直接構成し、モック対象のメソッドに向けられたテストページを引き出して、設定したポイントを取得しました。 さて、テスト機能では、有効なポイントのみがユーザーの画面に表示されることを確認しました。 pytestはフィクスチャをパラメータ化する機能があるため、2つのテストを記述する必要もありませんでした。両方のテストケースが1つのフィクスチャと1つのテストでカバーされています。



上記の例では、mock-APIはmountebank Web APIを介して直接構成されました。 実際のプロジェクトでは、多くのクライアントライブラリが記述されている高いレベルの抽象化でmountebankを使用することをお勧めします。 pythonのみの場合、すでに3つあります。 お気に入りの言語が存在するはずです 。



この記事では、mountebankの機能のほんの一部のみを示しました。 詐欺師を扱うためのその他の基本的なリクエストに加えて、外部システムのAPIへのリクエストのプロキシ、 tcpプロトコルレベルでのモック、jsインジェクションなどの強力な機能も未解決のままでした。



したがって、このツールに興味がある場合は、ツールの名前に一致するように非常に機知に富んだ言語で書かれたドキュメント （mountebank-（英語）からトリックスター）へようこそ。