キャッチャーを使用したマイクロサービスのエンドツーエンドのテスト

こんにちは マイクロサービスのエンドツーエンドのテストのための新しいツール-Catcherを紹介したい

テストする理由

なぜe2eテストが必要なのですか？ マーティン・ファウラーは 、より単純なテストを支持してそれを避けることを推奨します。

ただし、テストが高いほど、書き換えは少なくなります。 単体テストはほぼ完全に書き直されています。 機能テストは、深刻なリファクタリングの場合にも時間を費やす必要があります。 エンドツーエンドのテストでは、ビジネスロジックをテストする必要があり、変更の頻度は少なくなります。

さらに、すべてのマイクロサービスの完全なテスト範囲でさえ、それらの正しい相互作用を保証しません。 開発者は、プロトコルを誤って実装する場合があります（名前/データ型のエラー）。

または、ドキュメントのデータスキームに依存する新しい機能を実装し、スキームの不一致エラーの形で製品環境に驚きを覚えます。データの混乱やデータスキームの更新を忘れた人。

また、関連する各サービスのテストはグリーンになります。

自動テストを行う理由

本当に。 私の以前の勤務地では、自動化されたテストの展開に時間を費やすことは、長すぎ、困難で、費用がかかると判断されました。 システムは大きくありません（一般的なカフカを使用した10〜15個のマイクロサービス）。 CTOは、「テストは重要ではなく、主なことはシステムが機能することだ」と判断しました。 いくつかの環境で手動でテストしました。

外観（一般的なプロセス）：

1. 他の開発者に同意する（新しい機能に参加しているすべてのマイクロサービスを展開する）
2. すべてのサービスを展開する
3. リモートkafkaに接続します（dmzのダブルssh）
4. k8sログに接続します
5. kafkaにメッセージを手動で作成して送信します（god jsonに感謝）
6. ログを見て、動作したかどうかを理解してください。

そして今、このチョコレートの樽には少しのタールがあります。ほとんどのテストでは、ユーザーを作成する必要がありました。既存のものを再利用するのは難しいからです。

まず、システムが分散しているという事実により、いくつかのサービスにはユーザーに関する情報を含む独自のデータベースがありました。

第二に、kafkaは永続的なデータストレージに使用されました。 つまり データベース内の情報が削除/変更されても、サービスは再起動時にそれを読み返します。

新しいテストユーザーの登録はどのようなものでしたか（概算）：

1. データ（名前、メールなど）を入力します
2. 個人データの入力（住所、電話番号、税務情報）
3. 銀行データの入力（実際には、銀行データ）
4. 20〜40の質問に答えます（すでに痛みを感じていますか？）
5. IDNowの IDを確認します（サンドボックスが時々過負荷になるため、 開発環境で無効にしたことを神に感謝します。ステージでは約5分以上です）
6. このステップでは、サードパーティシステムでアカウントを開く必要があり、フロントエンドでは何もできません。 sshでkafkaにアクセスし、模擬サーバーとして動作する必要があります（アカウントが開いているというメッセージを送信します）
7. 次に、モデレーターの個人アカウントの別のフロントエンドに移動して、ユーザーを確認する必要があります。

スーパー、ユーザーが登録されました！ 軟膏が少し飛ぶようになりました。一部のテストでは、複数のテストユーザーが必要です。 また、テストが初めて失敗することもあります。

そして、新機能の検証とビジネスチームからの確認はどうですか？

次の環境でも同じことを繰り返す必要があります。

言うまでもなく、しばらくすると、彼はボタンを押しただけで、ユーザーを登録する猿のように感じ始めます。

一部の開発者（通常はフロントエンド）は、kafkaへの接続に問題がありました。 そして、端末にバグがあり、80文字以上の文字列があります（tmuxについて誰もが知っていたわけではありません）。

長所 ：

• 何も設定/書き込む必要はありません。 実行中の環境で正しくテストします。
• 高い資格は必要ありません（安い専門家ができます）

短所 ：

• 時間がかかります（遠くになるほど、より多くなります）
• 通常、新しい機能のみがテストされます（既存の機能が壊れているかどうかは明確ではありません）
• 多くの場合、熟練した開発者が手動テストに従事しています（高価な専門家が安価な作業を行います）。

自動化する方法は？

頭をうなずいて「はい、それは素晴らしいプロセスです。みんな彼らが何をしているのか知っています」と言ってこれを読んだら、興味はありません。

自家製のe2eテストには2つのタイプがあり、どちらのプログラマーがより自由だったかによって異なります。

• テスト環境に存在するバックエンド。 テストロジックを保護します。テストロジックは、エンドポイントを通過します。 CIとの相互作用により、部分的に自動化することもできます。
• 同じワイヤードロジックを使用したスクリプト。 唯一の違いは、どこかに行ってそこから実行する必要があることです。 CIを信頼している場合は、自動的に実行することもできます。

いいですね。 問題？

はい、そのようなテストは、それらを書いた人が知っていることについて書かれています。 通常、これらはrubやpythonなどのスクリプト言語であり、この種のことをすばやく簡単に書くことができます。 ただし、bashスクリプトの束、C、またはよりエキゾチックなものに出くわすことがあります（スクリプトが拡張可能でなくなったため、bashスクリプトで自転車をpythonにコピーするのに1週間かかりました。 。

プロジェクト例はこちら

長所 ：

• 自動化

短所 ：

• 開発者の資格には追加の要件がある場合があります（Javaで開発しており、テストがPythonで作成されている場合）
• 記述されたコードをテストするためのコードの記述（誰がテストをテストしますか？）

準備はできていますか？

もちろん、 BDDの方向を見てください。 きゅうり 、 ゲージがあります。

要するに、開発者は特別な言語でビジネスシナリオを記述し、コード内のスクリプトのステップを実装します。 通常、この言語は人間が読める形式であり、開発者だけでなくプロジェクトマネージャーも読み書きできると想定されています。

スクリプトは、ステップの実装とともに別のプロジェクトにあり、サードパーティ製品（Cucumber / Gauge / ...）によって実行されます。

スクリプトは次のようになります。

Customer sign-up ================ * Go to sign up page Customer sign-up ---------------- tags: sign-up, customer * Sign up a new customer with name "John" email "jdoe@test.de" and "password" * Check if the sign up was successful
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして実装：

 @Step("Sign up as <customer> with email <test@example.com> and <password>") public void signUp(String customer, String email, String password) { WebDriver webDriver = Driver.webDriver; WebElement form = webDriver.findElement(By.id("new_user")); form.findElement(By.name("user[username]")).sendKeys(customer); form.findElement(By.name("user[email]")).sendKeys(email); form.findElement(By.name("user[password]")).sendKeys(password); form.findElement(By.name("user[password_confirmation]")).sendKeys(password); form.findElement(By.name("commit")).click(); } @Step("Check if the sign up was successful") public void checkSignUpSuccessful() { WebDriver webDriver = Driver.webDriver; WebElement message = webDriver.findElements(By.className("message")); assertThat(message.getText(), is("You have been signed up successfully!")); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

完全なプロジェクトはこちら

長所 ：

• ビジネスロジックは人間が読める言語で記述され、1か所に保存されます（ドキュメントとして使用できます）
• 既製のソリューションが使用され、開発者はそれらの使用方法を知るだけでよい

短所 ：

• マネージャーはスクリプトを読み書きしません
• 仕様とその実装の両方に従う必要があります（これはコードの記述と仕様の編集です）

それでは、なぜキャッチャーなのでしょうか？

もちろん、プロセスを簡素化するために。

開発者はjson / yamlにスクリプトのみを記述し、Catcherがそれらを実行します。 スクリプトは、連続して実行されるステップで構成されます。例：

 steps: - http: post: url: '127.0.0.1/save_data' body: {key: '1', data: 'foo'} - postgres: request: conf: 'dbname=test user=test host=localhost password=test' query: 'select * from test where id=1'
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Catcherはjinja2テンプレートをサポートしているため、上記の例ではワイヤード値の代わりに変数を使用できます。 グローバル変数は、（アンサンブルのように）インベントリファイルに保存し、環境から取得して、新しいものを登録できます。

 variables: bonus: 5000 initial_value: 1000 steps: - http: post: url: '{{ user_service }}/sign_up' body: {username: 'test_user_{{ RANDOM_INT }}', data: 'stub'} register: {user_id: '{{ OUTPUT.uuid }}' - kafka: consume: server: '{{ kafka }}' topic: '{{ new_users_topic }}' where: equals: {the: '{{ MESSAGE.uuid }}', is: '{{ user_id }}'} register: {balance: '{{ OUTPUT.initial_balance }}'}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

さらに、テストステップを実行できます。

 - check: # check user's initial balance equals: {the: '{{ balance }}', is: '{{ initial_value + bonus }}'}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

また、他のスクリプトからいくつかのスクリプトを実行することもできます。これは、コードのクリーンさと再利用（タグシステムを介したステップの一部のみの開始、起動の遅延など）に優れた効果をもたらします。

 include: file: register_user.yaml as: sign_up steps: # .... some steps - run: include: sign_up # .... some steps
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

スクリプトを挿入して使用することで、リソースを待機する問題を解決できます（起動中にサービスを待機します）。

既製の組み込み手順と追加のリポジトリに加えて）、Python（ ExternalStepを継承するだけ）または他の言語でモジュールを書くことができます：

 #!/bin/bash one=$(echo ${1} | jq -r '.add.the') two=$(echo ${1} | jq -r '.add.to') echo $((${one} + ${two}))
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして使用：

 --- variables: one: 1 two: 2 steps: - math: add: {the: '{{ one }}', to: '{{ two }}'} register: {sum: '{{ OUTPUT }}'}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

スクリプトはdockerファイルに配置され、CIを介して実行されます。

また、この画像をMarathon / K8sで使用して、既存の環境をテストできます。 現時点では、テストプロセスをさらに簡単かつ便利にするために、バックエンド（AnsibleTowerのアナログ）に取り組んでいます。

長所 ：

• コードを記述する必要はありません（カスタムモジュールの場合のみ）
• インベントリファイルを使用した環境の切り替え（アンサンブルなど）
• 独自のモジュールを使用できます（どの言語でも、shでも）

短所 ：

• 人間が読めない構文（BDDツールと比較して）

結論の代わりに

このツールを作成したとき、私は通常、テストに費やす時間を短縮したかっただけです。 そのため、新しい会社はすべてこのようなシステムを作成（または書き換え）する必要がありました。

ただし、このツールは予想よりも柔軟性が高いことが判明しました。 誰かがこの記事（またはツール自体）に興味がある場合は、Catcherを使用して集中移行を整理し、マイクロサービスシステムを更新する方法を説明できます。

更新

コメントで指摘されたように、このトピックは公開されていません。

ここで最も物議を醸す論文を示しようとします。

• エンドツーエンドテストは単体テストではありません。 この記事では、すでにM. Fowlerについて言及しました。 単体テストはテストバックエンドプロジェクト（標準tests
  
  
  
  ディレクトリ）にあり、コードがCIに変更されるたびに実行されます。 また、e2eテストは別のプロジェクトです。通常は時間がかかり、参加しているすべてのサービスの相互作用をテストし、プロジェクトのコードについては何も知りません（ブラックボックス）。
• 統合（および以下）テストにCatcherを使用しないでください。 高価です。 現在のバックエンドの言語でテストを書く方がはるかに高速です。 エンドツーエンドのテストが必要なのは、ビジネスロジックが2つ以上のサービスに分散している場合のみです。
• キャッチャーもBDDです。 私の観点から、Gauge / Cucumberに対する主な利点は、既製のモジュールと追加の容易さです。 理想的には、テストのみが記述されます。 前の会社では、プログラミングを一切行わずに、標準コンポーネントで4つのテストすべてを作成しました。 したがって、資格要件（およびそのような専門家の価格）は低くなります。 json / yamlの知識と仕様を読む能力のみが必要です。
• Catcherテストを作成するには、Catcher-DSLを学習する必要があります。 悲しいかな、これは本当です。 最初は、マイクから直接、テストに自分で書いてもらいたかった。 しかし、その後、私は彼らがその後私を不必要に解雇すると思った;）上記のように-キャッチャーDSLは標準のjson / yamlとステップ仕様です。 基本的に新しいものはありません。
• 標準のテクノロジーを使用して、独自のものを作成できます。 ただし、マイクロサービスについて話している。 これは、多数の異なる技術と核兵器と多数のチームです。 また、javaコマンドjunit + testcontainersが明白な選択である場合、アーランチームは別のものを選択します。 最上位に30以上のチームがある大企業では、すべてのテストを新しいインフラストラクチャ/ QAチームに提出することを決定します。 この動物園で彼らがどれほど幸せか想像できますか？
• 4〜5個のe2eテストがある場合は、すべてのスクリプト言語ですべてを記述し、それを忘れることができます。 ただし、ロジックが時間とともに変化する場合は、2〜4年後にリファクタリングを行い、テストのビジネスロジックとアクセスメソッドの実装をテスト対象のコンポーネントに直接配布する必要があります。 そのため、最終的にはキャッチャーを作成しますが、それほど柔軟ではありません。 これを理解するには4つの実装が必要でした;）