Integration testing

kjohann

Hi

I wonder if there is a way to do integration tests with the lighstreamer server by creating a "fake server". Play Framework offers a "fakeapplication" out of the box (see http://www.playframework.com/documentation/2.1.1/JavaTest). I know that this is a full blown web application framework, and not focused on real time push like Lightstreamer, but I still hope that a similar concept exists for Lightsreamer. If so - could someone offer an example?

marco.testa

Hi Kjohann,

Actually Lightstreamer doesn't have a "fake server" like the one provided by Play Framework for integration test implementation.
Also the fact that it's essentially based on a publish-subscribe model, makes the integration test a bit more complex compared to a request-reply model.
If I understand, what you are asking for is a way to simulate an adapter pushing to the server a given sequence of updates, and verify the client receives a given snapshot when it subscribes, and receives subsequent updates provided by the adapter after the subsciption.

kjohann

Yes - that is exactly what I am asking. I know that Play is based on a request/reply model, but from what I have understood, it is also possible to use the "fakeapplication" to test WebSocket functionality as well...

marco.testa

Actually everything is testable, but ... not everything is easily testable - even if it should actually be.
Play did a great job, offering tools to make tests easily.
But testing a publish-subscribe architecture has some pitfalls we have to be aware of.
Like in a request-reply model, the system under test is the web app, which lives in a dummy server (a server specifically designed to be instantiated in a test) and interacts with a dummy client.
The system under test must be treated as a black box, and this is just what happens when, in a request-reply model test, the client sends a request and checks the expected reply.
In a publish-subscribe model however you must have some sort of control on what and when is published, in order to verify what and when the client is supposed to receive.
This must be designed carefully, otherwise the risk is to test a system that actually is not any more the system it ought to be.

kjohann

The ultimate scenario would be if I could write something like:
@Test
public void testSomeServerFunc() {
startServer();
call dataAdapter.subscribe(*some data*)
//Have some way of listening to the events that goes to the client
}

From what I have understood, this shouldn't be too hard to accomplish, but I have no idea where to start with Lighstreamer. With Node.js and socket.io for instance, it does not seem that tricky to test a publish-subscribe architecture:
https://github.com/LearnBoost/socket.io/blob/master/test/socket.io.js

Mone

Hi kjohann,

You actually can't do that: Lightstreamer is not a class you can instantiate and launch, it has its own main that needs to be executed: the startServer call you show has to ask the shell to launch a Lightstreamer server. Also you have to wait for the server to be up and running before you can perform any subscription

Also you can't call dataAdapter.subscribe, you need to create a client (you can use our Java client lib for that) and actually perform a subscription toward the server that in turn will forward it to the adapter.
If you need the client and the adapter to be in the same process you may create the client inside your dataadapter (let me know if I should expand on this)

Note that with Lightstreamer you can't publish a message to a client unless the clients subscribe to the related item.

HTH

kjohann

I don't think making a client inside the adapter would solve my problem. That would mean that the class I'm testing is different from the actual class. However, I have though about two possible solutions: Either use a framework like FluentLenium to write tests that uses the browser, or write a "test-client" in java. Either way, I will have to manually start the server before running the tests, which is no all that optimal..

Dario Crivelli

In principle, you can launch the Server inline in your test java process, by invoking the "main" method in the com.lightstreamer.LS class and supplying the path of the configuration file (you can refer to LS.sh for the details).
However, the Server would still lean on an underlying file system for completing the configuration stuff and finding the Adapters to load.
Moreover, it wouldn't be possible to close the Server and keep on with the test, eventually launching a new Server instance afterwards.

Would the above restrictions be acceptable?
Launching the Server in this way, on the other hand, would allow you to define and instantiate the fake Adapter instances inline in your test code and have them executed by the Server.
Note that the Server instantiates the Adapter instances by itself, based on the class specified in "adapters.xml";
but you could write generic wrapper classes for both the Data and Metadata Adapter and have these classes attach at runtime to your running instances of the fake Adapters and delegate to them.

Otherwise, you should have your test code run the Server as an external process and then stop it by leveraging the provided scripts.
In this case, it might not be possible to define the fake Adapters inline in the test code.

kjohann

Yes, those restrictions are acceptable. As long as I can start and stop the server in my tests, I think that I will be able to write the testcases that I want. Either by the use of fake adapters or by FluentLenium.