たくさんのブラウザー拡張機能を作成します (一般的な各ブラウザーで同じ機能を使用します)。コードの一部が共有されることを願っていますが、これについてはまだわかりません。確かに、一部の拡張機能はネイティブ API を使用します。私は TDD/BDD の経験があまりないので、このプロジェクトからこれらのアイデアを追い始める良い時期だと思いました。
問題は、それを処理する方法がわからないことです。ブラウザごとに異なるテストを作成する必要がありますか? これらのテストをどこまで進める必要がありますか? これらの拡張機能は非常に単純です。ローカル ストレージ内の一部のデータ、ページの更新、および Web ソケットを介したリッスンです。
そして、なぜ私にとって難しいのかについての私の観察-プラットフォームにも依存する多くの動作があり、モデルはそれほど多くないためです。
ブラウザー拡張機能のテストも私にとっては困難でしたが、Selenium によって駆動されるブラウザーから同時に呼び出すことができるいくつかの異なる領域でテストを実装することにしました。
私が使用する手順は次のとおりです。
最初に、特定の URL にアクセスするだけでアクティブ化できる拡張コードに統合されたテスト コードを記述します。拡張機能がその URL を確認すると、テストの実行を開始します。
次に、拡張機能のテストを有効にするページで、サーバー側のテストを実行して API が確実に機能することを確認し、そこで問題を記録してログに記録します。呼び出されたメソッド、それらにかかった時間、およびエラーを記録します。したがって、拡張機能が呼び出したメソッド、Web パフォーマンス、ビジネス ロジックのパフォーマンス、およびデータベースのパフォーマンスを確認できます。
最後に、ブラウザーを自動的に呼び出してその特定の URL を指定し、Selenium を使用する任意のクライアント システムで、他のテスト情報、エラーなどと共にブラウザーのパフォーマンスを記録します。
このようにして、ブラウザー、拡張機能、サーバー、アプリケーション、およびデータベースの観点からテストを分類し、特定のテスト セットに従ってそれらをすべてリンクすることができます。すべてをまとめるには少し手間がかかりますが、完了すると、非常に優れた拡張テスト フレームワークを作成できます。
通常、単一のコードベースを維持するためにクロスブラウザー拡張機能の開発には crossrider を使用しますが、これは任意のフレームワークまたはネイティブ拡張機能で行うことができます。Selenium は気にしません。特定のページに移動し、対話してテストを実行できるようにします。
このアプローチの良い点の 1 つは、ライブ ユーザーにも使用できることです。拡張機能のサポートを提供している場合は、ユーザーにテスト URL にアクセスしてもらうと、すぐに拡張機能とサーバー側のパフォーマンスが表示されます。もちろん、Selenium テストは取得できませんが、この方法で多くの問題をキャプチャできます。これは、さまざまなブラウザーやブラウザー バージョンに対してコーディングする場合に非常に役立ちます。