こんにちは、Habrasociety! ほとんどのITスタッフと同様に、私は何か新しいもの、クールなもの、何らかの形で世界に影響を与えるもの、または少なくとも他の人々にほとんど利益をもたらさないものを作成するのが好きです。 WebSocketsでオンラインシステムをテストするための以下に説明するツールがまさにそのようなものであることを願っています。
背景
ほとんどのアイデアは、活発で多様な仕事から生まれたものであり、このアイデアも例外ではありません。 クロスプラットフォームゲームをテストするには、多くのテストを作成する必要がありました。 最も便利な組み込み機能は、Xcode環境のiOSに提供されています(Obj-Cを使用してAndroidのJavaのアルゴリズムを単純に書き換えたため、単体テストなしで実行することにしました)。 サーバーでは、ローカルで実行されるときに内部から多くのアルゴリズムをテストできます。また、HTTP要求の正しい処理を確認するために、 requests
ライブラリを使用してPythonスクリプトを簡単に作成できます。
ただし、クライアントとサーバーの相互作用のためにWebSocketsを介して通信チャネルを追加する必要がある場合、テストに必要な注意を払っていませんでした。 その結果、ゲームではWebSocketsを介して新しいユーザーを作成することはできず、アプリケーションはそれらを正確に使用していました...
本番環境でこのエラーが表示される主な理由は、WebSocketsをテストする簡単な方法がなかったことです。HTTPとは異なり、各リクエストに回答があります。 または何も送信しませんが、任意の数の異なるメッセージを取得します。
インターネットを検索しても、このトピックに関する推奨事項は見つかりませんでした。 たぶん私は不十分に検索したかもしれませんし、この技術はまだ若すぎて、大規模なプロジェクトでは独自のシステムがテスト用に記述されており、小さなものではすべてが手動で行われているかもしれません。 しかし、グローバルなソフトウェアの連続性に小さな空白が見られ、それを急いで閉じました。
その結果、 WebSocket Testing Engine JavaScriptライブラリー(簡単に言うとWSTester )と、テストコード付きのJSファイルを受け入れる既製のGUIを介して作業するためのWebページが作成されました。 すべてのソースはGithubで入手できます。
動作原理
WSTesterはステートマシンとして動作します。 実行フローは入力され、独立して順番に実行され、 ユニットテストと見なすことができます。 実行の各スレッドはJavaScriptの配列またはディクショナリであり、 unitsで構成されており、各時点で現在のユニットは1つだけです。
インデックス1のユニットは、ストリーム内で最初に呼び出され、後続のものは任意です。 ストリームが配列の場合、次のユニットは現在の+ 1に等しいインデックスを持つと見なされますが、次のユニットのインデックスを変更することもできます。 ストリームがディクショナリである場合、次のユニットのインデックスを常に自分で指定する必要があります。
ユニットオブジェクトの構造は次のとおりです。
{ name: string, enter: function () {}, task: function (ws, ref) {}, condition: function (data) {}, key: string, val: any type, finalise: function (ws) {}, }
name
フィールドは、ユニットに関する情報を表示するために使用され、新しい現在のユニットに移動する場合はenter
およびtask
が使用され、新しいメッセージを受信する場合はcondition
、 key
、 val
およびfinalise
が使用されます。
受信したメッセージが次の条件のいずれかを満たす場合、ユニットは正常に完了したと見なされます。
-
condition
関数が指定されている場合、引数受信メッセージを持つ関数がtrue
または次のユニットのインデックスを返す場合、ユニットは成功します。 -
key
とval
が指定されている場合、受信したメッセージにkey
と等しい名前のフィールドがあり、このフィールドの値がval
の値と等しい場合、ユニットは成功しkey
。 ところで、val
が配列の場合、その値はすべて個別にチェックされます。 -
key
が指定されているがval
が指定されていない場合、受信したメッセージにkey
と等しい名前のフィールドがある場合、ユニットは成功しkey
。
ユニットが起動された瞬間から、指定された時間内に適切なメッセージが受信されなかった場合、現在のユニットとストリームは失敗したと見なされます。
上記の情報は、 既製のWSTesterインターフェースを介して実行できるテストを作成するのに十分です。 仕事の原則についてのより多くの詳細はこことここにあります 。
インターフェイスでは、さまざまな設定を変更できます。WebSocketsサーバーアドレス、ユニットが失敗するまで適切なメッセージを待機する時間、各ストリームに新しい接続を作成する必要があるかどうか、ユニット間の時間です。 最大の自動化のために、同じパラメーターをJSテストファイルに設定できます。 また、GUIは、指定されたURLで、またはコンピューターから直接テストファイルを受け入れることができます。
JSライブラリ自体を使用する場合、リストされたオプションに加えて、ログ出力関数、接続の再接続後に呼び出される関数、および成功したスレッドと失敗したスレッドの数ですべてのテストが実行された後に呼び出される関数を指定できます。
使用例
主な機能は、前述のゲームのプロジェクトの一環として、HTTPリクエストのテストに類似したものとして開発されましたが、その後、他のいくつかのサービスで動作するようにテストおよび拡張されました。 以下は、いくつかのテスト、説明、およびファイルとサービスへのリンクです。
- data_toy.js- 論理ゲームTacticToyの実際のテストの変更。 4スレッド、16ユニットが含まれます。 ファイルを実行します 。
特徴:condition
; 辞書のようなストリーム。condition
およびref.next
を使用してユニットをスキップしcondition
。 - data_gdax.js - GDAX WebSocket APIのサンプルテスト。 3つのスレッド、3つのユニットが含まれます。 ファイルを実行します 。
機能:配列としてのval
。args.split
。 - data_block.js- ブロックチェーントランザクションWebSocket APIのサンプルテスト。 1つのストリームと3つのユニットが含まれます。 ファイルを実行します 。
機能:finalise
ます。 - data_ether.jsは、 Etherscan Block Explorer WebSocket APIのサンプルテストです。 2つのストリームと6つのユニットが含まれます。 ファイルを実行します 。
機能:辞書のようなストリーム。ref.next
;args.split
。
これらのテストにはWSテストエンジンのすべての機能が含まれていますが、まだ限界に達しておらず、想像力の大きな範囲を残していることに注意してください:外部変数、関数、オブジェクトを定義して使用し、ユニットでそれらを操作できますファンシールールなどに基づくユニット間の循環遷移 JavaScript言語はそのようなことに非常に気を配っています。
PS
- もちろん、上記のエラーは他の方法で明らかにすることもできますが、物語の本質はそれではありません。
- なぜjavascriptですか? それは非常に強力であると同時に、WebSocketがすぐにサポートされる軽量のクロスプラットフォーム言語であり、インターフェイス(HTML + CSS)を簡単に追加できるからです。
- 使用する声明や用語は正確になるよう努めますが、誰かがエラーに気付いた場合は、scるのではなく、親切にコメントしてください。
- 残念ながら、事前登録が不要なWebSocketでオープンAPIを見つけることができませんでした。 リストを拡張するための提案があれば、自由に選択肢を提案してください。