Refactor existing web socket code base in tests

[nazarhussain]

There are different occurrences of web socket code specially for tests which don't smell good to me. I am listing such cases here, may be I am wrong and its the right approach, but we should have second opinion on it.

Improper use of stub or wrong naming convention

https://github.com/LiskHQ/lisk/blob/6cdfef14ebc7afaeb5ae68efcf141e75c7ef2633/api/ws/rpc/ws_rpc.js#L56

getClientRPCStub is it really a stub? Stubs are associated to sinon-js all around the code, if its really behaving like a stub, then why its part of main code. If its really not a stub then we should use some proper name to clear the confusion.

Different intializer for WS Server in code and test

For core app we have an initializer for WS
https://github.com/LiskHQ/lisk/blob/6cdfef14ebc7afaeb5ae68efcf141e75c7ef2633/app.js#L295-L297
In code we have another initializer
https://github.com/LiskHQ/lisk/blob/6cdfef14ebc7afaeb5ae68efcf141e75c7ef2633/test/common/ws/server_process.js#L62-L64
We should create a single code for it using factory pattern. So same code logic create web socket server for app as well as tests.

Different codebase for ws-client testing

There is a file ws/client.js which was used during testing and also starting web socket server. Now all the tests are moved to explicit declaration of

var WAMPClient = require('wamp-socket-cluster/WAMPClient');
var scClient = require('socketcluster-client');

While the purpose of ws/client.js was to provide common reuseable wrapper to avoid duplicate code. If we are not using ws/client.js then we should delete it completely. But we should avoid duplicate code usage.

As earlier said seeking for second opinion on these points.

[jondubois]

I agree with all of these points.

[jondubois]

After investigating the current test suite some more and discussing with colleagues, I've come to the following conclusions about our current integration test suite:

• It is not flexible; it is very tightly coupled with the internal logic of the node.
• It is good/thorough in terms of code feature coverage; so it serves its current purpose well (assuming that the Lisk core logic doesn't change too much - I.e. Suitable for versions 1.x.x).

Most of these tests will likely have to be rewritten (or discarded) when we move to Lisk 2.0 and so there is no point refactoring them until we start implementing modules in 2.0.

For the migration between v1.x.x and v2.x.x, we should lean more on functional and network tests.