Good day, Habrasoobschestvo! Like most IT people, I like to create something new, cool, something that can somehow influence the world or at least bring a small benefit to other people. I hope that the tool described below for testing online systems with WebSocket is just such a thing.

Prehistory

Most of the ideas are born as a result of active and diverse work, and this idea is no exception. To test my cross-platform game, I had to write a lot of tests. For iOS in the Xcode environment, the most convenient built-in functionality is provided, (I simply rewrote algorithms in Java for Android with Obj-C, decided to do without unit tests). On the server, many algorithms can be tested from the inside when it is started locally, and to check the proper handling of HTTP requests, you can easily write a Python script with the requests library.

However, when for the interaction of the client server I had to add a communication channel on the WebSocket, I did not pay the necessary attention to testing it. As a result, the game did not have the opportunity to create a new user through Web Sockets, and the application used them ... Looking at the statistics, I quickly suspected something was wrong, but took decisive action only after a month or two.

The main reason for the appearance of this error in production was that there were no easy ways to test Web Sockets - because unlike HTTP, where every request has an answer, you can send as many messages as you want to the server and not get a response at all; or do not send anything, but get any number of different messages.

Searching on the Internet, I did not find any recommendations on this topic. Maybe I was looking badly, or maybe this technology is still too young, and for large projects we write our own systems for testing, and for small projects everything is done manually. However, I saw a small void in the global software continuum and hurried to close it.

The result was the JavaScript library WebSocket Testing Engine (in short, WSTester ) and a web page for working with it through a ready-made GUI that accepts a JS file with test code. All sources are available on GitHub.

Principle of operation

WSTester works as a finite state machine - execution threads are sent to the input, they are executed independently and sequentially, they can be considered as unit tests . Each execution thread is an array or dictionary of JavaScript, it consists of units , and only one current unit exists at a time.

The first unit in the stream is called with index 1, the subsequent ones can be any. If the stream is an array, then the following is considered a unit with an index equal to the current + 1, but you can also change the index of the next unit. If the stream is a dictionary, then it is always necessary to specify the index of the next unit on its own.

The structure of the unit object is as follows:

 { name: string, enter: function () {}, task: function (ws, ref) {}, condition: function (data) {}, key: string, val: any type, finalise: function (ws) {}, } 

The name field is used to display information on the unit, enter and task are used when moving to a new current unit, and condition , key , val and finalise when a new message is received.

A successfully completed unit is considered when the received message satisfies one of the conditions:

• If the condition function is specified, the unit is completed successfully, if the function with the argument received message returns true or the index of the next unit.
• If key and val are specified, then the unit is completed successfully, if the received message has a field with the name equal to key and the value of this field equal to the value val . By the way, if val is an array, then all its values ​​will be checked separately.
• If key is specified, but not val , then the unit is completed successfully if the received message has a field with the name equal to key .

If, since the launch of the unit, no suitable messages have been received within the specified time, the current unit and stream are considered failed.

The information described above is sufficient for writing tests that can be run through a ready-made WSTester interface . Much more and more about the principles of work can be found here and here .

In the interface, you can change different settings: the WebSockets server address, the waiting time for a suitable message until the unit collapses, whether you need to create new connections for each stream, the time between units. The same parameters can be set in the JS test file for maximum automation. Also, the GUI can accept test files at a specified URL or directly from a computer.

When using the JS library itself, in addition to the listed options, you can set a log output function, a function that is called after the connection is reconnected, and a function that is called after all the tests have been executed with the numbers of successful and failed threads.

Examples of using

The main functionality was developed within the project of the aforementioned game, as an analogue of tests for HTTP requests, however, it was subsequently tested and expanded in work with several other services. Below are a few tests, descriptions and links to files and services.

• data_toy.js - modification of real tests of the logic game TacticToy . Contains 4 streams, 16 units. Run the file .
  Features: condition ; stream as a dictionary; skipping units using condition and ref.next .
• data_gdax.js - sample test for the GDAX WebSocket API . Contains 3 streams, 3 units. Run the file .
  Features: val as an array; args.split .
• data_block.js - sample test for Blockchain transaction WebSocket API . Contains 1 stream and 3 units. Run the file .
  Features: finalise .
• data_ether.js - sample test for The Etherscan Block Explorer WebSocket API . Contains 2 streams and 6 units. Run the file .
  Features: flow like a dictionary; ref.next ; args.split .

It is worth noting that although these tests contain all the functionality of the WS Testing Engine, they still do not reach any limits, leaving a huge scope for imagination: you can define and use external variables, functions, objects, and work with them in units, you can do cyclic transitions between units according to sophisticated rules, etc. JavaScript language to such things is very convenient.

PS

• Of course, the mentioned error could have been revealed in other ways, but this is not the essence of the story.
• Why javascript? Because it is powerful enough and at the same time a lightweight cross-platform language, in which WebSocket is supported out of the box, and you can easily add an interface to it (HTML + CSS).
• I try to be precise in my statements and the terms used, but if someone notices mistakes, please do not scold, but comment kindly.
• Unfortunately, I managed to find a few open APIs on WebSokethe, where preliminary registration is not needed. If you have any suggestions for expanding the list, feel free to offer your options.

Library code and other files on GitHub .