Best practices for Integration Tests on a Java Client application

I am looking for some suggestion about creating integration (unit) tests for a client application written in Java.

Ideally I would like to start an in memory Standalone Pravega service.

 try (PravegaStandaloneForTests server = bootPravegaStandaloneForTests() {   
  String  connectionString = server.getConnectionString();
   run application that writes/reads to Pravega....
}

Context: We are going to implement an integration between Pravega and EmailSuccess.com, EmailSuccess.com will be a source of data, it will write a stream of events to Pravega. We want to create integration tests with JUnit.

[eolivelli]

@ravisharda this is my working test

https://github.com/eolivelli/pravega-testing/blob/master/src/test/java/PravegaIntegrationTest.java

This is the minimal set of dependencies: https://github.com/eolivelli/pravega-testing/blob/master/pom.xml

Issues:

• you need to explicitly clean up netty dependencies, from the dependency tree you got several versions, with and without the ‘-all’ suffix
• you need to explicitly add grpc

I didn’t have to add pravega-shared-authplugin, maybe it is automatically imported by the java client, that you need in order to make any meaningfull test

Regarding the ‘start’ method I can raise a PR. Regarding the dependencies I prefer that someone expert of the release process would do it. It would be very good to have some integration tests that create a simple project like the one on my github. Something that is “far” from Pravega codebase and this way we are sure that it is not affected by transitive dependencies injected by parent modules

[ravisharda]

@eolivelli

Can you please confirm that correct Maven dependency for tests is this one ?

A second dependency in addition to the one you mention will be needed. Both of these are required:

1. io.pravega:pravega-standalone:0.7.0
2. io.pravega:pravega-shared-authplugin:0.7.0

(That using Pravega standalone requires the second one, is a bug. Previously, the first one was sufficient. I’ve created issue 4795 for this.)

I see that LocalPravegaEmulator#start is not “public”. But we can call it using Java reflection. We can make it public. Once we have finished the first run of integration tests I will send a PR in order to make it public

Yes, that’s an issue. We should make it public so that people can use the LocalPravegaEmulator. Would you consider raising a pull request for it?

In the meantime, you can use the InProcPravegaCluster that the LocalPravegaEmulator uses internally. Something like this:

 InProcPravegaCluster inProcCluster = InProcPravegaCluster.builder()
                .isInProcZK(true)
                .zkUrl("localhost:" + 2181)
                .zkPort(2181)
                .isInMemStorage(true)
                .isInProcController(true)
                .controllerCount(1)
                .enableRestServer(true)
                .restServerPort(9091)
                .controllerPorts(new int[]{9090})
                .isInProcSegmentStore(true)
                .segmentStorePorts(new int[]{6000})
                .segmentStoreCount(1)
                .containerCount(4)
                .enableTls(false)
                .enableAuth(false)
                .build();

       inProcCluster.start();
       
      // Add test logic

       inProcCluster.close();

cc @derekm