4分で単体テストまたは17,000テストの最適な並列化

今日は、PHPUnitとTeamCityを使用してPHPコードのテストを最適化するために開発したユーティリティについて説明します。 同時に、私たちのプロジェクトはウェブサイトだけでなく、モバイルアプリケーション、Wapサイト、Facebookアプリケーションなどでもあり、開発はPHPだけでなく、C、C ++、HTML5、など

ここで説明する方法は、すべての言語、テストシステム、環境に完全に適合しています。 したがって、私たちの経験は、PHPのWebサイト開発者だけでなく、他の開発分野の代表者にとっても有用です。 さらに、近い将来、TeamCityやPHPUnitに必ずしもバインドせずに、システムをオープンソースに移行する予定です。確実に誰かに役立つでしょう。

なぜこれが必要なのですか？

ユニットテストは必須です（ 私たちはそれを本当に信じています！ ）何十人もの人々が取り組んでいる深刻なプロジェクトのコンポーネントです。 そして、プロジェクトが大きいほど、より多くの単体テストがあります。 単体テストが多いほど、実行時間が長くなります。 実行時間が長ければ長いほど、開発者とテスターは起動を「ソフトに無視する」ことに決めます。

当然、これはテストタスクの品質と速度にプラスの影響を与えることはできません。 テストはリリース前にのみ完全に実行され、土壇場で「このテストが失敗したのはなぜですか」という精神で明確化が始まります。そして、多くの場合、すべては「そのように分解して、修正します！」に帰着します。 そして、問題がテストにある場合は良いことです。 テストコード内にある場合はさらに悪化します。

この状況から抜け出す最善の方法は、テストの実行時間を短縮することです。 しかし、どのように？ 各タスクをテストする場合、影響を受けるコードをカバーするテストのみを実行できます。 しかし、これはすべてが順序通りであることを100％保証することはまずありません：結局、何千ものクラスで構成されるプロジェクトでは、それらの間の微妙な関係を追跡することが時々難しいです（ 本によると、テストされたクラスの制限を超えないでください、そしてさらに良い-テスト方法。しかし、あなたはそのようなテストを見たことがありますか？ ）。 したがって、複数のスレッドですべてのテストを並行して実行する必要があります。

怠zyなものに対する最も簡単なソリューションは、たとえば、自分の手でいくつかのPHPUnit XML構成ファイルを作成し、それらを別々のプロセスで実行することです。 しかし、それは短時間で十分です。これらの構成の継続的なサポートが必要になり、一部のテストまたはパッケージ全体が欠落する可能性が高くなり、実行時間が最適とはほど遠いでしょう。

遅延の最も簡単な解決策は 、テストをスレッド間で均等に分割する単純なスクリプトを作成することです。 しかし、ある時点では、テストの数が絶えず増加しているため、すべてが異なる速度で動作し、スレッド間で実行時間の差が生じるため、それ自体も使い果たします。 したがって、それらを扱うより効果的で制御された方法が必要です。

結論 ：テストをストリーム間で自動的かつ均等に分散し、テストでコードカバレッジを独立して制御する、管理しやすいシステムが必要です。

検索する

PHPUnitは非常に一般的なシステムであるため、おそらく誰かがすでに似たようなことをして、検索を開始したと考えました。

最初の結果は期待を裏切るものではありませんでした。さまざまな程度の可用性と機能レベルのソリューションが多数ありました。 これらは、bashスクリプト、PHPスクリプト、PHPUnitのラッパー、さらにはシステム自体の非常に複雑で包括的なパッチです。 私たちはそれらのいくつかを試し始め、コードを掘り下げ、プロジェクトに適応しようとし、膨大な数の問題、あいまいさ、論理的エラーに直面しました。 これは驚くべきことでした。100パーセントの実績のあるソリューションはまだ存在しないのでしょうか。

ほとんどのオプションは、次の2つのスキームのいずれかに従って構築されました。

• 必要なすべてのファイルを探し、ストリーム間で均等に分割します。
• テストの一般的なキューを順次処理し、それらをPHPUnitに「フィード」する特定の数のスレッドを開始します。

最初の方法の欠点は明らかです。テストが最適な方法で分散されないため、当然ながら作業の速度が上がりますが、多くの場合、他のすべてのスレッドよりも3〜4倍長いスレッドが動作します。

2番目の方法の欠点はそれほど明白ではなく、PHPUnitの内部構造の興味深い機能に関連しています。 まず、PHPUnitプロセスの各開始には、テスト環境のエミュレート、テストクラスの数と構造に関する情報の収集など、多くのアクションが含まれます。 第二に、多数のテストを開始するとき、PHPUnitはすべてのテストのすべてのデータプロバイダーをかなりc明かつスマートな方法で収集し、ディスクおよびデータベースアクセスの回数を最小限に抑えます（ 繰り返します：本当に有効な単体テストはありません！ ）、しかしこれは利点ですシステムに一度に1つずつテストを行うと失われます。 私たちの場合、この方法はテストで膨大な数の不可解なエラーを引き起こしました。テストのシーケンスはほとんど常に起動ごとに変わるため、キャッチして繰り返すのは非常に困難でした。

また、PHPUnit開発者がすぐにマルチスレッドサポートを実装したいという情報も見つかりました。 しかし、問題は、これらの約束が1年以上前のものであるということです。プロジェクトの開発に関するコメントはけちで、大まかな予測さえないため、この決定を当てるのは時期尚早です。

これらのオプションのすべてを数日かけて研究した結果、完全に設定した問題を解決できるものはなく、プロジェクトの現実に最大限に適応した独自のものを作成する必要があるという結論に達しました。

創造性の粉

最初のアイデアは表面にありました。 ほとんどのテストクラスはほぼ同じ時間で動作すると判断しましたが、数十倍または数百倍実行されるものもあります。 したがって、これらの2種類のテストを分離する（ つまり、これらの「低速」テストを個別に決定する）ことを決定し、互いに別々に実行することにしました。 たとえば、最初の5つのスレッドですべての「高速」テストを実行し、他の3つのスレッドですべての「低速」テストを実行する必要があります。 結果は非常に良好で、同じスレッド数で、テストは2スレッドバージョンよりも約2倍速く合格しましたが、異なるスレッドの時間の広がりは依然として顕著でした。 したがって、テストをできるだけ均等に配布するには、テストの実行時間に関する情報を収集する必要があります。

次に思いついたのは、各実行後にテストの時間を節約し、この情報をその後の組み合わせに使用することです。 ただし、このアイデアには欠点もありました。 たとえば、統計をどこからでもアクセスできるようにするには、データベースなどの外部ストレージに保存する必要がありました。 2つの問題があります。1つ目は、この操作を完了する具体的な時間です。2つ目は、複数のユーザーが同時にこのリポジトリにアクセスするときに競合が発生します（ もちろん、トランザクション、ロックなどを使用して解決されますが、速度、および競合の解決はプロセスを遅くします ）。 特別な条件または特定の周期でデータを保存することは可能ですが、これらはすべて排他的な「クランチ」です。

これから、誰もが読み取り専用に行く特定の隔離された場所で統計を収集する必要があり、記録は別のもので行われることになりました。 TeamCityを思い出したのはこの瞬間でしたが、それについては後で詳しく説明します。

別の問題があります：テストの実行時間は、サーバーのパフォーマンスが急激に低下するなど、ローカルでも、サーバーの負荷が増加または減少するときにも常に変動する可能性があります（ テストは、開発および実行している同じマシンで実行されますリソースを集中的に使用するスクリプトの開発者は、テストの時間に大きく影響します ）。 つまり、統計を最大限に更新するには、平均値を累積して使用する必要があります。

このユーティリティの設定方法は？ 最初の実装では、すべての制御はコマンドラインパラメーターによって実行されました。 つまり、ユーティリティをPHPUnitのパラメーターを使用して実行し、起動したプロセスに渡し、独自のプロセスを追加しました-たとえば、実行するテストの完全なリスト（ そして驚くべきPHPUnitの起動行は数千文字の長さでした）。 これは不便であり、送信されたパラメータをもう一度考えさせ、新しいエラーの出現に寄与することは明らかです。 多くの実験を経て、最も簡単な解決策がようやく実現しました。標準のPHPUnit構成XMLファイルを使用して、それらの設定を変更し、いくつかのカスタムXMLタグを構造に追加できます。 したがって、これらの構成ファイルを使用すると、純粋なPHPUnitとユーティリティの両方を同じ結果で実行できます（ もちろん、この場合の速度の増加は考慮されません ）。

解決策

それで、何時間もの計画、開発、深刻なバグの検索、マイナーなバグの発見の後、私たちは現在動作するシステムに来ました。

マルチスレッドランチャー（または、愛称で「ランチャー」と呼ぶ）は、3つの独立したクラスで構成されています。

• テスト実行時間の統計を収集および保存するためのクラス。
• これらの統計を取得するためのクラスと、テストの配布さえも。
• PHPUnit構成ファイルを生成し、そのプロセスを開始するためのクラス。

最初のクラスはTeamCityで動作します。 彼女は定期的にすべてのテストを実行するビルドを起動し、その後統計コレクターを含めます。 このコラボレーションには、長所と短所の両方があります。 一方では、TeamCity自体は実行中のすべてのテストの統計を収集しますが、他方では、TeamCity APIはこの情報を操作するためのツールを提供しません（ ネイティブでも、さらに開発されたREST APIでもないため）、データベースに直接連絡する必要があります彼女は働いています。

ここで小さな問題に直面しています。 スレッド間でテストを均等に分散するための情報の単位としてテストクラスファイルに提供された元のアーキテクチャ（ これはPHPUnit構成ファイルの最も自然な方法であるため ）。 また、TeamCityは統計をファイルにリンクせずに、個別のテストに保存します。 したがって、コレクターはデータベースからテスト統計を読み取り、テストをクラスと、クラスをファイルと相関させ、この形式で統計を保存します。



これはかなりリソースを消費するタスクのように思えるかもしれませんが、通信「クラス=>ファイル」をキャッシュするシンプルなシステムを作成しました。新しいクラスが出現し、各開始時の数がそれほど多くない場合にのみコレクターによってハードワークが行われます。

統計は、過去7日間に7つのコピーで独自のデータベースに保存されます。 毎日再び収集されますが、ファイルを配布する場合、先週全体のデータが使用され、統計が新しいほど、平均時間を計算する際の「重み」が高くなります。 したがって、テストの実行時間を1回増やしても統計に大きな影響はなく、恒久的な変更はすぐに考慮されます。

2番目のクラスは、可能な限り単純なアルゴリズムで各ストリームのファイルリストを生成します。 データベースから情報を受け取り、すべてのファイルを実行時間ごとに最大から最小にソートし、「最も空きのあるストリーム内の各後続ファイル」の原則に従ってストリームごとにそれらを配布します。 多くのテストがあり、大きなテストよりも小さなテストが多いという事実により、すべてのスレッドの予想される動作時間は数秒だけ異なります（ もちろん、実際のスレッドはわずかに大きくなりますが、その差はそれほど重要ではありません ）。
右側の図では、列はフローであり、各「ブリック」は個別のテストであり、その高さは合格に要する時間に比例します。

3番目のクラスは、最も興味深いものを扱います。 メインモードでは、標準のPHPUnit構成を入力として受け入れ、テストディレクトリと特定のファイルを指定します。 テストを「遅い」（ 一部のテストの時間は外部要因に依存し、他のテストとは別に実行する必要があります ）および「分離」（ 他のすべてのテストが完了した後に別のスレッドで実行される ）としてマークする機能があります 。 次に、ランチャーは、必要なTestListenerなどの必要なすべてのパラメーターを使用して独自のPHPUnit構成を形成し、テストスイートは各スレッドで実行するファイルのリストです。 したがって、その後は、この構成でいくつかのPHPUnitプロセスを開始し、必要なテストスイートを指定するだけで十分です。 メインモードに加えて、テストをデバッグする機会があります。最新またはその他の生成された構成で開始する、標準のTestListener PHPUnitを使用する、別の順序でテストを実行するなど

TestListener'ahといえば（ これは、実行されたテストに関する情報を表示するために使用される標準のPHPUnitインターフェイスです）。 最初は、ランチャーはデフォルトでPHPUnitと同じ形式で情報を表示していました。 しかし、利便性を高めるために、情報をよりコンパクトで読みやすいものにする独自のリスナーを作成し、STDOUTやSTDERRのインターセプトなどの新機能も追加しました。

さらに、TeamCityに情報を期待する形式で表示するためのTestListenerがあります（ 結果として1回の起動でのテキストレポートの重みが5メガバイトに達するほど怖い ）。

まとめ

今、いくつかの数字。
8スレッドで17000以上のテストを実行します（ さらに、通常の状況では1分ですべてが通過する「低速」テスト用に3つのテストを追加 ）。
最良の場合（ テストサーバーの標準負荷で ）、スターターの助けを借りてテストを行うと、1つのスレッドで40〜50分、均等に分散した場合は8〜15分であるのに対して、3.5〜4分で合格します。
サーバーの負荷が高い場合、ランチャーは状況にすばやく適応し、8〜10分で解決します。 テストを均等に配布すると、少なくとも20〜25分間働きました...そして、1つのスレッドでテストが完了するのを一度も待ちませんでした。



その結果、TeamCityから受け取った統計のおかげでサーバーの負荷の変化に独立して適応し、フローごとにテストを自動的に分散し、管理と構成が容易なシステムを手に入れました。

このようなテストの実行を高速化したのはなぜですか？

• 最初に、タスクのテストの速度を上げました。
• 第二に、頻繁にテストを実行するため、タスクブランチがリリースブランチに大量にマージされる際に致命的なエラーをキャッチする確率が大幅に低下しました。
• 第三に、TeamCityエージェントは大幅に緩和されました。テストは1つのビルドから遠く離れて実行され、QAエンジニアからの特別なタスクのための自由な時間を実際に持っています。
• 第4に、テスト用のタスクを送信するときにテストを自動的に実行できるようになったため、テスト担当者は、タスクコードを受信したときの状態に関する情報を取得できます。

次は？

システムを改善する方法については、まだ多くのアイデアと計画があります。 いくつかの既知の問題があります：時々、シングルスレッド起動から残ったテストの分離に困難があり、ワンクリックでランチャーを別のプロジェクトに転送することができません-そのため、システムは非常に印象的な結果を達成していますが、今後の作業の分野はまだ非常に大きいです。

近い将来（6月を楽しみにしています）、システムの完全なリファクタリングと改訂が行われ、オープンソースプロジェクトに変換できるようになります。

ランチャーにはユーティリティも組み込まれているため、1つのテストを多数のデータプロバイダーを含む複数のストリームに分割したり、環境を破壊するテストを探したり、特定のテストを破壊するコミットを決定したりできます。

さらに、システムアーキテクチャが変更されるため、開発者はランチャーをTeamCityから問題なくバインド解除して、たとえばJenkinsにバインドしたり、ローカルでのみ作業したりできます。

私たちのマルチスレッドランチャーは、ある種の革命やテスト自動化の新語であるとは言いたくありませんが、プロジェクトでは最高の側面を示し、いくつかの欠点にもかかわらず、他のすべてのパブリックソリューションよりもはるかに効率的に機能します。

QAエンジニアのイリヤクディノフ。