なぜですか？
残念ながら、サイトの初期段階では、品質保証は主に手動テストに限定されていました。 リリースサイクルが短いため、回帰テストを頻繁に実行する必要がありました。 多数のロケールが状況を悪化させました（チェックにロケールの数が掛けられました）。 手動テストのコストは大きく、サイトテストの自動化の利点は明らかでした。あなたは行動する必要がありました。
何が欲しい？
そこで、自動テストシステムの要件を作成し始めます。 かなり単純な欠陥の処理には貴重な時間が必要であることに気付きました。バグトラッカーに持ち込まれる欠陥の数を最小限に抑えたいと考えましたが、そのようなエラーは視野から失わないでください。 したがって、このような欠陥のある作業を自動テスト報告システムに割り当てることが決定されました。 報告は、非常に便利で、理解しやすく、有益で、楽しいものにする必要がありました。 フレンドリーなウェブチームのメンバーがレポートを見て、何が起きているのかをすぐに理解し、欠陥を修正できるようにしました。 それに応じて、開発者がサイトを修正し、テスターがテストを修正します。 その結果、「青信号」と運用中のGOがあります。
歴史的に、 Python開発言語という別の要件があります 。 残りの要望の詳細を省略して、将来の自動テストシステムの要件のリストを受け取りました。
- 便利で理解しやすい、有益な報告。
- テストの並行起動。
- テストのパラメーター化。
- ロケールのテストデータの継承。
- ユーザーに最も近い環境でのテスト。
- 誤検知の最小化。
- テスト環境の便利なサポートと提供。
- 独自の開発およびカスタマイズの最小限。
- オープンソース
- Python
選択の小麦粉
まず、 ロボットフレームワークに注目しました。 これは、 Acronisの出版物ですでに言及されている一般的なソリューションです。 インストールされ、試してみました。 もちろん、多くのプラスがありますが、今ではそうではありません。 私たちにとっての主な禁忌は、パラメータ化されたテストとそれらの結果の定期的な報告を伴うRFの作業です。 私たちが考案したテストの大半は、正確にパラメーター化されたテストであることに注意してください。 RFレポートでは、パラメーター化されたテストのケースの1つが失敗すると、テスト全体が失敗としてマークされます。 また、箱から出してすぐにRFを報告することは、ほとんどの人にとって不便でした。トライアルの自動テストの結果を解析するのに多くの時間がかかりました。 テストがより困難な場合に、キーワードを使用した特異な「単純な」テストの作成は困難な作業であることが判明しました。 同時に、Habrを含めたおかげで、YandexのAllureに注目を集めました。
私たちは、誰もがそれを気に入っており、誰もがこのシステムを使いたいと思っていました。これは非常に重要です。 このツールを研究し、プロジェクトが積極的に開発されていることを確認し、Pythonを含むさまざまな一般的なテストフレームワーク用の既製のアダプターを多数用意しています。 残念ながら（そして幸運なことに）pythonにはpytestフレームワーク専用のアダプターがあることがわかりました 。 私たちは見て、読んで、試しました-それはクールなものであることが判明しました。 Pytestは、既製および独自のプラグインによる大規模なオンラインコミュニティにより、使いやすく拡張可能な機能を多数実行できますが、テストのパラメーター化は必要な方法です！ 立ち上げ、いくつかの試用テストを作成しましたが、すべてが正常です。 問題はテストの並列実行です。ここでは、ソリューションの選択は小さく、 pytest-xdistのみです 。 インストール、起動、および...
軟膏で飛ぶ
pytest-xdistがAllure Pytest Adapterと競合していることが判明しました。 彼らは理解し始めました、問題は知られています、それは長い間議論されており、解決されていません。 また、ロケールのテストデータを継承するための既製のソリューションが見つかりませんでした。
秘密の材料
これらの問題を回避するために、Pythonでツール（ラッパー）を作成することにしました。 このラッパーは、継承を考慮してテストデータを準備し、テストに渡し、テスト環境データをテスト（ブラウザーなど）に渡し、指定された数のスレッドでテストを実行します。 テストが完了したら、異なるストリームで受信したレポートを1つにまとめ、最終データをWebサイトに公開します。
コマンドラインを介した各ユニットテストの並列呼び出しとして、彼らは非常に簡単に並列化を実装することにしました。 このアプローチでは、テストデータの転送を自分でテストする必要がありました。 pytestのフィクスチャのおかげで、これは数行の問題です。 重要 ！ また、（allure-python / allure / common.py）の数行をコメントアウトする必要があります。これは、allureアダプタのレポートディレクトリ内の「古い」ファイルを削除する役割を果たします。
パラメーター化されたテストのテストデータをtsvファイルに、静的テストデータをyamlに保存することが決定されました。 このデータが存在するディレクトリの名前と階層を使用して、テストデータがテストとロケールに属するかどうかを判断することにしました。 継承は、メインの基本ロケール「en-us」から実行され、一意のデータを削除、追加します。 また、テストデータでキーワード「skip」と「comment」を使用して、特定のテストケースの起動をキャンセルし、理由を示すこともできます。 このような継承は、たとえば、すべてのサイトのローカライズに同じデータを使用する必要がある場合、追加のパラメーターなしで自動的に継承が行われます。 ところで、これらのテスト構成（環境、タイムアウトなど）についても、ローカリゼーションに基づいてではなく、グローバル構成ファイルのテスト構成に基づいて継承が実装されました。
別のニュアンス
最初のレポートを受け取って、ロケールのコンテキストでテスト結果を表示する方が便利だと考え始めました。 各ロケールに独自の魅力レポートのコピーがあるという原則に基づいて、結果を分離することが最も便利であると考えました。 また、ロケールに関する一般的な情報を集約するために、簡単ですがかなりきれいなラッパーをすばやく作成しました。
私たちの喜びに影を落とした最後のものは、テスト環境での個々の起動のフリーズのケースでした。 テスト環境として、古典的なSeleniumを （実際の環境に最も近い環境として）使用することにしました。 セレンの多くのチェックでは、失敗は避けられません。 全員の「お気に入り」の誤検知に加えて、継続的な統合と本番環境への「青信号」が非常に困難になります。
私たちは考え出し、解決策を見つけました。 ハング-ラッパーの完了を克服しました。 個々のテストの最大実行時間を指定する機能を追加し、指定した時間実行されない場合は、おおよそ再起動します。 また、pytestのrerun -xfailsアドオンを使用して、 誤検知が削除されました。 このプラグインは、失敗したすべてのテストを自動的に再起動します。ここでも、テストまたは一般ごとに設定yaml-fileで試行回数を設定します。
エピローグ
そして最後に、ここにあります-初心者自動化機能の幸福：安定した、便利な作業システム。 メンテナンスが容易で、テストをできる限り迅速に、誤検出なしで実行でき、テスト結果に関する非常に便利なレポートを提供します。
PS
友人、Habréについてのあなたのフィードバックについて、私たちの経験がどれほど面白いかを理解したいと思います。 結果のターンキーソリューションをドッカーコンテナとして公開するというアイデアがあります。