Introduction

Nowadays surfing the web we are used to variety of modern conveniences, one of which is an ability to contact customer support in real time using online chat. The chat allows you to ask a question about certain product or service, request status and details of your order, consult a technician or file a complaint. All that without ever having to leave the web site.
Of course, such a thing was possible long before the introduction of the WebSocket protocol. Technically you could achieve something like that using Comet, which is a term for a bunch of hacky techniques to implement two-way interaction such as hidden iframe and http polling. Let’s just say this way of doing it was far from ideal. Fortunately, we got WebSocket, which unlike Comet was specifically designed for persistent two-way communication. In this article we are going to briefly consider the protocol’s intricacies and eventually learn how to test it. One more significant addition: this tools should work from private networks, therefore online services are not suitable for us. Dear reader, if you would like to support our cause, please:

• Subscribe to our Medium channel;
• Star our WebSocket interface testing application’s repository (https://github.com/Wissance/wstester); Ok, let’s proceed!

The difference between WebSocket and HTTP

In the very beginning the web relied entirely on HTTP which was designed to be stateless and as such work in the request-response fashion. Basically what it means is, every time you send a request your browser establishes a new connection with the server and once you receive the response the connection gets terminated. So in case you need to receive notifications or updates from the server there is no way to retain the connection. Your only option is or more accurately was so-called HTTP polling, which is a technique, where your browser repeatedly sends the HTTP request to the server(polls the server) to determine if there was some kinda change. The server either responds immediately or holds the connection until there is an update, the former is known as HTTP long polling.
If you have an online chat on your web site which for whatever reason employs any kinda polling, the client (your browser) has to constantly send HTTP requests in order to check for new messages. Such an approach generates a lot of unnecessary traffic and affects the server load which worsens its performance.

Now that WebSocket is around you no longer have to build such a monstrosity. Unlike HTTP WebSocket allows you to establish a persistent full-duplex(both ways) TCP connection which is gonna be alive for as long as you need. So, you can use WebSocket to send and receive messages from the server as if it was a regular TCP connection, which it is.

The testing tools

So how do we test it?
WebSocket requires an open TCP connection, besides, often frontend and backend are being developed separately and sometimes by different teams. I was tasked with WebSocket interface development many times and as there was no tool to test it I had to do it manually. I always wanted some kinda universal utility I could use regardless of the backend.
Actually it’s possible that I wasn’t looking hard enough for these things. But I assure you, there aren’t a lot of them out there to date. Recently I found out that new versions of Postman support WebSocket protocol. Sounds great, but unfortunately, Postman, just like any tool really got few disadvantages which make it not necessarily ideal for every situation:

1. There is something wrong with the way Postman stores its collections. One day something weird happened and I lost all of mine. All the requests just disappeared.
2. Postman is a single window application (what if i want to establish many (10+) connections is it possible or not, i have not check);
3. Postman is bloated and heavy; We developed our solution long before Postman added WebSocket support and considering all the aforementioned Postman flaws it’s still great in its own way.

Wstester, our tool to test WebSocket

When we were designing it we decided to make it as simple as possible. You could find it here

The key features are:

• No need for bundlers, package managers and so on;
• The code has only one dependency, which is JQuery and iy could be easily removed;
• No heavy CSS frameworks like Bootstrap, only one css file (Pure.css);
• Application automatically prepends WebSocket protocol ws:// to the address you enter;
• Intuitive UI;
• Portable (could be used in any private networks)

This is what the web interface looks like (to test it open tester.html file in your browser):
Here is a little video tutorial (Ru language) with a bit of theory and the testing process demonstration.

Conclusion

The application could use some work. There are few minor issues with the interface a*nd it lacks certain features such as request storage and so on. If there were enough people interested in this project (at least 30 stars on github*) we would be willing to spend our time on its further development. Thanks for reading and good luck!