🏥 👨🏽‍🎨 🙅🏻 数百のクライアントバージョンに対応するMonolith：テストの作成および管理方法 🕺🏾 🔏 🗜️

みなさんこんにちは！

私はBadooサーバーチームのバックエンド開発者です。昨年のHighLoad会議で、プレゼンテーションを作成しました。これをテキストバージョンで共有します。この投稿は、複雑なビジネスロジックをテストしたい人だけでなく、バックエンドのテストを自分で書いてレガシーコードのテストで問題を経験する人にとって最も有用です。

何について話しますか？最初に、開発プロセスと、それがテストの必要性とこれらのテストを作成したいという欲求にどのように影響するかについて簡単に説明します。次に、テストの自動化ピラミッドの下部から上部に移動して、使用するテストの種類について議論し、各テストの内部のツールとそれらの助けを借りて解決する問題について説明します。最後に、これらすべてを保守および実行する方法を検討してください。

開発プロセス

開発プロセスを示しました。

ゴルファーはバックエンド開発者です。ある時点で、通常は2つのドキュメントの形式で開発タスクが彼に渡されます。ビジネスサイドからの要件と、バックエンドとクライアント（モバイルアプリケーションとサイト）間の相互作用のプロトコルの変更を説明する技術ドキュメントです。

開発者はコードを記述して、すべてのクライアントアプリケーションよりも早く動作するようにします。すべての機能は、いくつかの機能フラグまたはA / Bテストによって保護されています。これは技術文書で規定されています。その後、現在の優先順位と製品ロードマップに従って、クライアントアプリケーションがリリースされます。バックエンド開発者の私たちにとって、特定の機能がクライアントに実装されることはまったく予測できません。クライアントアプリケーションのリリースサイクルはやや複雑で長いため、製品マネージャーは文字通り優先順位を調整しています。

会社が採用している開発文化は非常に重要です。バックエンドの開発者は、バックエンドでの実装の瞬間から、この機能を最初に実装する予定だった最後のプラットフォームでの最後の統合までの機能を担当します。

この状況は非常に起こりえます。6か月前にいくつかの機能を展開し、クライアントチームはそれを長時間実装しませんでした。会社の優先順位が変更されたためです。彼らは言う：「あなたが6ヶ月前に洗い流したこのことを覚えていますか？彼女は働きません。」そして、新しいタスクに従事する代わりに、火を消します。

そのため、開発者はPHPプログラマーにとっては珍しい動機を持っています-統合フェーズで問題ができるだけ少なくなるようにします。

機能が機能することを確認するために、最初に何をしたいですか？

もちろん、最初に頭に浮かぶのは、手動テストを実施することです。アプリケーションを取得しますが、方法はわかりません。この機能は新しいため、顧客は6か月で処理します。まあ、手動テストでは、バックエンドのリリースから統合の開始までに経過する時間については、クライアントに影響を与えないという保証はありません。

そして、ここで自動テストが役立ちます。

単体テスト

最も簡単なテストは単体テストです。バックエンドのメイン言語としてPHPを使用し、ユニットテストのフレームワークとしてPHPUnitを使用します。今後は、すべてのバックエンドテストがこのフレームワークに基づいて記述されていると言います。

単体テストでは、孤立した小さなコードをいくつかカバーし、メソッドや関数のパフォーマンスをチェックすることがよくあります。つまり、ビジネスロジックの小さな単位について話しています。単体テストは、データベースやサービスにアクセスするものと相互作用してはなりません。

ソフトモック

開発者が単体テストを作成するときに直面する主な問題は、テストできないコードであり、通常これはレガシーコードです。

簡単な例。 Badooは12歳で、かつては非常に小さなスタートアップでしたが、何人かの人々によって開発されました。スタートアップは、テストなしでまったく成功しました。その後、十分に大きくなり、テストなしでは生きていけないことに気付きました。しかし、この頃には、機能する多くのコードが書かれていました。テストのためだけに書き直さないでください！それはビジネスの観点からはあまり合理的ではありません。

そのため、テストを作成するプロセスをより安く、より速くする小さなオープンソースライブラリSoftMocksを開発しました。すべてのインクルード/必要なPHPファイルをインターセプトし、オンザフライでソースファイルを変更されたコンテンツ、つまり書き換えられたコードに置き換えます。これにより、任意のコードのスタブを作成できます。ライブラリの機能の詳細を示します。

開発者向けのこのようなもの：

//mock  \Badoo\SoftMocks::redefineConstant($constantName, $newValue); //mock  : , ,  \Badoo\SoftMocks::redefineMethod( $class, $method, $method_args, $fake_code ); //mock  \Badoo\SoftMocks::redefineFunction( $function, $function_args, $fake_code );

このような単純な構造の助けを借りて、必要なものをすべてグローバルに再定義できます。特に、標準のPHPUnitメーカーの制限を回避できます。つまり、静的メソッドとプライベートメソッドをモックし、定数を再定義し、さらに多くのことを行うことができます。これは通常のPHPUnitでは不可能です。

しかし、問題が発生しました。SoftMocksを使用すると、テスト可能なコードを作成する必要がないようです。グローバルモックを使用してコードをいつでも「コーム」でき、すべて正常に動作します。しかし、このアプローチは、より複雑なコードと「クランチ」の蓄積につながります。そのため、状況を管理できるようにするいくつかのルールを採用しました。

新しいコードはすべて、標準のPHPUnitモックで簡単にテストする必要があります。この条件が満たされると、コードはテスト可能になり、小さなピースを簡単に選択してテストすることができます。
SoftMocksは、単体テストに適さない方法で記述された古いコードで使用できます。また、他の方法ではコストが高すぎる/長すぎる/難しい（必要性を強調する）場合にも使用できます。

これらのルールへの準拠は、コードレビュー段階で慎重に監視されます。

突然変異試験

それとは別に、単体テストの品質について言いたいと思います。多くの人がコードカバレッジなどのメトリックを使用していると思います。しかし、残念ながら、彼女は1つの質問に答えていません。「良いユニットテストを書いたことがありますか？」実際には何もチェックせず、単一のアサートを含まないテストを作成した可能性がありますが、優れたコードカバレッジを生成します。もちろん、例は誇張されていますが、状況は現実からそれほど遠くありません。

最近、突然変異試験を導入し始めました。これはかなり古いですが、あまりよく知られていない概念です。このようなテストのアルゴリズムは非常に簡単です。

コードとコードカバレッジを取得します。
parsimを実行し、コードの変更を開始します。trueからfalse、> to> =、+ to-（一般的に、あらゆる点で害があります）;
このような変更の変更ごとに、変更された文字列をカバーするテストスイートを実行します。
テストが失敗した場合、テストは良好であり、実際にコードを壊すことはできません。
テストに合格した場合、ほとんどの場合、カバレッジにもかかわらず十分に効果的ではないため、いくつかのアサートを行うために（またはテストでカバーされていない領域がある）、それらをより詳しく調べる価値があるかもしれません。

HumbugやInfectionなど、PHP用の既製のフレームワークがいくつかあります。残念ながら、それらはSoftMocksと互換性がないため、私たちには向いていませんでした。したがって、同じことを実行する独自の小さなコンソールユーティリティを作成しましたが、内部コードカバレッジ形式を使用し、SoftMocksとは友好的です。現在、開発者はそれを手動で開始し、彼が書いたテストを分析しますが、開発プロセスにツールを導入することに取り組んでいます。

統合テスト

統合テストの助けを借りて、さまざまなサービスやデータベースとの相互作用を確認します。

ストーリーをさらに理解するために、架空のプロモーションを作成し、テストでカバーしましょう。プロダクトマネージャーが会議チケットを最も熱心なユーザーに配布することを決定したと想像してください。

次の場合にプロモを表示する必要があります。

「Work」フィールドのユーザーは「programmer」を示します。
ユーザーはA / BテストHL18_promoに参加し、
ユーザーは2年以上前に登録されています。

「チケットを取得」ボタンをクリックして、チケットを配布するマネージャーに転送するために、このユーザーのデータをリストに保存する必要があります。

このかなり単純な例でも、単体テストを使用して検証できないことがあります-データベースとの相互作用。これを行うには、統合テストを使用する必要があります。

PHPUnitが提供するデータベースの相互作用をテストする標準的な方法を検討してください。

テストデータベースを上げます。
DataTablesとDataSetsを準備します。
テストを実行します。
テストデータベースをクリアします。

そのようなアプローチで待つのにどんな困難がありますか？

DataTablesおよびDataSetsの構造をサポートする必要があります。テーブルのレイアウトを変更した場合、これらの変更をテストに反映する必要がありますが、これは必ずしも便利ではなく、追加の時間が必要です。
データベースの準備には時間がかかります。テストを設定するたびに、そこに何かをアップロードし、何らかの種類のテーブルを作成する必要があります。テストが多い場合、これは長くて面倒です。
そして、最も重要な欠点：このようなテストを並行して実行すると、テストが不安定になります。テストAを開始し、彼が作成したテストテーブルへの書き込みを開始しました。同時に、テストBを起動しました。テストBは、同じテストテーブルで動作することを望んでいます。その結果、相互の妨害やその他の予期しない状況が発生します。

これらの問題を回避するために、小さなDBMocksライブラリを開発しました。

DBMocks

動作原理は次のとおりです。

SoftMocksを使用して、データベースを操作するすべてのラッパーをインターセプトします。
いつ

クエリはモックを通過し、SQLクエリを解析してDB + TableNameをプルし、接続からホストを取得します。
tmpfsの同じホストで、元のテーブルと同じ構造の一時テーブルを作成します（SHOW CREATE TABLEを使用して構造をコピーします）。
その後、モックを介してこのテーブルに送信されるすべてのリクエストを、新しく作成された一時的なリクエストにリダイレクトします。

これにより何が得られますか？

構造を常に管理する必要はありません。
テストは、ソーステーブルのデータをその場で一時テーブルにリダイレクトするため、破損することはありません。
作業中のMySQLのバージョンとの互換性をテストしていますが、リクエストが突然新しいバージョンとの互換性を失った場合、テストはそれを確認してクラッシュします。
そして最も重要なことは、テストが分離され、テストを並行して実行しても、テストテーブルの名前に各テストに固有のキーを追加するため、ストリームが異なる一時テーブルに分散されることです。

APIテスト

ユニットテストとAPIテストの違いは、このGIFでよく示されています。

ロックは正常に機能しますが、間違ったドアに取り付けられています。

テストはクライアントセッションをシミュレートし、プロトコルに従ってリクエストをバックエンドに送信でき、バックエンドは実際のクライアントとしてリクエストに応答します。

ユーザープールをテストする

このようなテストを正常に作成するには何が必要ですか？プロモーションのショーの条件に戻りましょう。

「Work」フィールドのユーザーは「programmer」を示します。
ユーザーはA / BテストHL18_promoに参加し、
ユーザーは2年以上前に登録されています。

どうやら、ここではすべてがユーザーに関するものです。そして実際には、APIテストの99％には、すべてのサービスとデータベースに存在する許可された登録ユーザーが必要です。

どこで入手できますか？テスト時に登録を試みることができますが、次のことができます。

それは長く、リソースを消費します。
テストを完了した後、このユーザーを何らかの方法で削除する必要があります。これは、大規模なプロジェクトについて話している場合にはかなり重要な作業です。
最後に、他の多くの負荷の高いプロジェクトと同様に、バックグラウンドで多くの操作を実行します（さまざまなサービスへのユーザーの追加、他のデータセンターへのレプリケーションなど）。テストはそのようなプロセスについて何も知りませんが、実行の結果に暗黙的に依存している場合、不安定になるリスクがあります。

Test Users Poolというツールを開発しました。次の2つのアイデアに基づいています。

毎回ユーザーを登録するわけではありませんが、何度も使用しています。
テスト後、ユーザーデータを元の状態（登録時）にリセットします。これを行わないと、ユーザーは他のテストからの情報で「汚染」されるため、テストは時間とともに不安定になります。

次のように機能します。

ある時点で、実稼働環境でAPIテストを実行したいと考えました。なぜこれが必要なのでしょうか？開発インフラストラクチャは本番と同じではないからです。

生産インフラストラクチャを常に縮小サイズで繰り返すことを試みていますが、develが完全なコピーになることはありません。新しいビルドが期待どおりで問題がないことを確実に確認するために、新しいコードを実稼働データとサービスで動作する実稼働前クラスターにアップロードし、そこでAPIテストを実行します。

この場合、テストユーザーを実際のユーザーから分離する方法を考えることが非常に重要です。

テストユーザーがアプリケーションで実際に表示されるようになったらどうなりますか。

分離する方法は？各ユーザーにはis_test_user

フラグがあります。登録段階で、 yes

またはno

になり、変更されなくなります。このフラグにより、すべてのサービスでユーザーを分離します。また、統計を歪めないように、テストユーザーをビジネス分析およびA / Bテストの結果から除外することも重要です。

より簡単な方法で進むことができます。すべてのテストユーザーが南極に「移転」したという事実から始めました。ジオサービスがある場合、これは完全に機能する方法です。

QA API

ユーザーだけでなく、特定のパラメーターが必要です。プログラマーとして働き、特定のA / Bテストに参加し、2年以上前に登録されました。テストユーザーの場合、バックエンドAPIを使用して職業を簡単に割り当てることができますが、A / Bテストに入ることは確率的です。また、ユーザーがプールにいつ登場したかわからないため、2年以上前の登録条件を一般に満たすことは困難です。

これらの問題を解決するために、QA APIがあります。実際、これはテストの裏口であり、ユーザーデータをすばやく簡単に管理し、クライアントとの通信のメインプロトコルをバイパスして状態を変更できる、十分に文書化されたAPIメソッドです。これらのメソッドは、QAエンジニアおよびUIおよびAPIテストで使用するために、バックエンド開発者によって作成されています。

QA APIは、テストユーザーの場合にのみ適用できます。対応するフラグがない場合、テストはすぐに失敗します。ユーザー登録日を任意の日付に変更できるQA APIメソッドの1つを次に示します。

したがって、テストユーザーのデータをすばやく変更して、プロモーションの表示条件を満たせるようにする3つの呼び出しのようになります。

「作業」フィールドには、「プログラマー」が表示されます。

addUserWorkEducation?user_id=ID&works[]=Badoo,
ユーザーはA / BテストHL18_promoに参加します。

forceSplitTest?user_id=ID&test=HL18_promo
2年以上前に登録：

userCreatedChange?user_id=ID&created=2016-09-01

これはバックドアであるため、セキュリティについて考えることが不可欠です。いくつかの方法でサービスを保護しました。

ネットワークレベルで分離：サービスはオフィスネットワークからのみアクセスできます。
リクエストごとにシークレットを渡します。シークレットなしでは、オフィスネットワークからでもQA APIにアクセスできません。
メソッドはテストユーザーでのみ機能します。

リモートモック

APIテストのリモートバックエンドを使用するには、モックが必要になる場合があります。何のために？たとえば、実稼働環境でのAPIテストがデータベースへのアクセスを開始する場合、そのデータがテストデータから消去されることを確認する必要があります。さらに、モックはテスト応答をテストにより適したものにするのに役立ちます。

3つのテキストがあります。

Badooは多言語アプリケーションです。複雑なローカライズコンポーネントがあり、ユーザーの現在地の翻訳をすばやく翻訳および受信できます。ローカライザーは、翻訳の改善、トークンを使用したA / Bテストの実施、より成功した製剤の探索に常に取り組んでいます。そして、テストを行うと、サーバーから返されるテキストを知ることができません-いつでも変更できます。ただし、RemoteMocksを使用して、ローカリゼーションコンポーネントに正しくアクセスできるかどうかを確認できます。

RemoteMocksはどのように機能しますか？テストでは、バックエンドにセッション用に初期化するよう要求し、後続のすべてのリクエストを受信すると、バックエンドは現在のセッションのモックをチェックします。存在する場合、SoftMocksを使用して単純に初期化します。

リモートモックを作成する場合は、どのクラスまたはメソッドを何に置き換える必要があるかを示します。このモックを考慮して、後続のすべてのバックエンドリクエストが実行されます。

 $this->remoteInterceptMethod( \Promo\HighLoadConference::class, 'saveUserEmailToDb', true );

それでは、APIテストを収集しましょう。

 //       $app_startup = [ 'supported_promo_blocks' => [\Mobile\Proto\Enum\PromoBlockType::GENERIC_PROMO] ]; $Client = $this->getLoginedConnection(BmaFunctionalConfig::USER_TYPE_NEW, $app_startup); //  $Client->getQaApiClient()->addUserWorkEducation(['Badoo, ']); $Client->getQaApiClient()->forceSplitTest('HL18_promo'); $Client->getQaApiClient()->userCreatedChange('2016-09-01'); //     $this->remoteInterceptMethod(\Promo\HighLoadConference::class, 'saveUserEmail', true); //,   ,   $Resp = $Client->ServerGetPromoBlocks([]); $this->assertTrue($Resp->hasMessageType('CLIENT_NEXT_PROMO_BLOCKS')); $PromoBlock = $Resp->CLIENT_NEXT_PROMO_BLOCKS; … //   CTA, ,   ,   $Resp = $Client->ServerPromoAccepted($PromoBlock->getPromoId()); $this->assertTrue($Resp->hasMessageType('CLIENT_ACKNOWLEDGE_COMMAND'));

このように簡単な方法で、バックエンドで開発され、モバイルプロトコルの変更が必要な機能をテストできます。

APIテストの使用規則

すべてがうまくいくように見えますが、再び問題が発生しました：APIテストは開発にはあまりにも便利であることが判明し、どこでもそれらを使用する誘惑がありました。その結果、意図していないAPIテストの助けを借りて問題を解決し始めていることがわかった。

なぜこれが悪いのですか？ APIテストは非常に遅いためです。彼らはネットワークに行き、バックエンドに向かいます。バックエンドはセッションを取得し、データベースと一連のサービスに行きます。そのため、APIテストを使用するための一連のルールを開発しました。

APIテストの目的は、クライアントとサーバー間の相互作用のプロトコルと、新しいコードの正しい統合を確認することです。
アクションの連鎖など、複雑なプロセスをそれらでカバーすることは許可されています。
これらを使用してサーバー応答のわずかな変動性をテストすることはできません。これは単体テストのタスクです。
コードのレビュー中に、テストを含めて確認します。

UIテスト

自動化のピラミッドを検討しているため、UIテストについて少し説明します。

Badooのバックエンド開発者はUIテストを作成しません。このため、QA部門に専任のチームがあります。すでに頭に浮かび、安定している機能をUIテストでカバーします。機能のかなり高価な自動化にリソースを費やすのは不合理であると考えているため、おそらくA / Bテストを超えないでしょう。

モバイルの自動テストにはCalabashを使用し、WebにはSeleniumを使用します。自動化およびテストプラットフォームについて説明します。

試運転

現在、100,000個のユニットテスト、6,000個の統合テスト、14,000個のAPIテストがあります。これらを1つのスレッドで実行しようとすると、最も強力なマシンでも、すべての実行に時間がかかります：モジュラー-40分、統合-90分、APIテスト-10時間。長すぎます。

並列化

この記事では、単体テストの並列化の経験について説明しました。

最初の解決策は明らかなようですが、テストを複数のスレッドで実行することです。しかし、私たちはさらに進んで、ハードウェアリソースを拡張できるようにするために、並列起動用のクラウドを作成しました。簡略化すると、彼の作品は次のようになります。

ここで最も興味深いタスクは、スレッド間でのテストの分散、つまり、それらのチャンクへの分割です。

それらを均等に分割できますが、すべてのテストが異なるため、スレッドの実行時間に大きな偏りがある可能性があります。すべてのスレッドはすでに到達しており、非常に遅いテストで「幸運」だったため、1つは30分ハングします。

複数のスレッドを開始して、一度に1つずつテストをフィードできます。この場合、デメリットはそれほど明白ではありません。環境を初期化するためのオーバーヘッドコストがあり、多数のテストとこのアプローチにより、重要な役割を果たすようになります。

私たちは何をしましたか？各テストの実行にかかる時間に関する統計の収集を開始し、統計に従って、1つのスレッドが30秒以内に実行されるようにチャンクを構成し始めました。同時に、テストを小さくするために、テストを非常に密にまとめます。

ただし、このアプローチには欠点もあります。 APIテストに関連付けられています。非常に遅く、多くのリソースを消費するため、高速テストの実行が妨げられます。

したがって、クラウドを2つの部分に分割しました。最初の部分では高速テストのみが起動され、2番目の部分では高速と低速の両方を起動できます。このアプローチでは、迅速なテストを処理できるクラウドの一部が常にあります。

その結果、単体テストは1分で、統合テストは5分で、APIテストは15分で実行され始めました。つまり、12時間ではなくフル実行に22分しかかかりません。

コードカバレッジテストの実行

巨大で複雑なモノリスがあり、良い方法では、ある場所での変更が別の場所で何かを壊す可能性があるため、すべてのテストを常に実行する必要があります。これは、モノリシックアーキテクチャの主な欠点の1つです。

ある時点で、毎回すべてのテストを実行する必要はないという結論に達しました。コードカバレッジに基づいて実行できます。

ブランチの差分を取る。
変更されたファイルのリストを作成します。
各ファイルについて、テストのリストを取得します。

それをカバーします。
これらのテストからセットを作成し、テストクラウドで実行します。

カバレッジを取得する場所開発環境のインフラストラクチャがアイドル状態のときに、1日に1回データを収集します。実行されたテストの数は著しく減少し、反対に、テストからのフィードバックの受信速度は著しく増加しました。利益！

追加のボーナスは、パッチのテストを実行できることでした。 Badooは長い間スタートアップではありませんでしたが、実稼働環境での変更の迅速な実装、ホットフィックスの迅速な投入、機能の展開、構成の変更を行うことができます。原則として、パッチを展開する速度は非常に重要です。新しいアプローチにより、テストからのフィードバック速度が大幅に向上しました。これは、完全な実行を長く待つ必要がないためです。

しかし、欠陥がなければ、どこにもありません。 , , , . . , code coverage . , , — , - , . .

API-, code coverage. , , . - , API- .

おわりに

, . - , , - .
≠ . code review , .
, , . .
. .
, ! , .

, Badoo PHP Meetup 16 . PHP-. , . ! 12:00, — YouTube- .

数百のクライアントバージョンに対応するMonolith：テストの作成および管理方法