End to end integration testing

[andreisavu]

End to end integration testing

[timrobertson100]

Looks good.

You asked on Twitter how others approach IT when using webservices. We have a fairly complex IT setup (3 WARs participating including SOLR) which is all orchestrated by standard maven plugins. We let Jenkins assign the random port using -Djetty.port=XXX. We keep the IT as a separate module in the multi-module project so can run it on a separate schedule as it takes quite some minutes to complete.

See the comments in the POM to understand how it works:
http://code.google.com/p/gbif-registry/source/browse/registry/trunk/registry-it/pom.xml

I'm not proposing you adopt the maven approach, but you asked.

[andreisavu]

Thanks! It makes sense to use maven for orchestration but it's also useful to be able to run them easily just from the IDE. I think there is no right answer but it's good to have options.

[alexandru]

Andrei, using ResourceTest is lighter on resources and it allows you to skip on loading resources you don't want.

In my opinion full integration testing are less useful for well-grown apps that have proper functional tests and real time monitoring, being more useful when tests are added after the application was built.

[andreisavu]

@alexandru I agree! I wrote this class because I needed a way to start the application with all the components registered (including filters, assets, custom servlets etc.). I can't use ResourceTest because the in-memory is not opening a server socket at all.

[timrobertson100]

@alexandru I also totally agree.
We use it mainly for system wide IT, rather than single app testing, where we really want to verify things like authentication checking etc (such as CAS cache redirections). Sometimes it is useful as well to verify upgrades on HTTP libraries are working as expected - you end up writing so much mock stuff otherwise.

[igstan]

I needed a real server so that I can test methods requiring HttpServletRequest injection (which is not supported by the in-memory container). What I ended up doing was using the GrizzlyWebTestContainer: https://gist.github.com/3016987

Unfortunately I had to copy/paste and modify the code in ResourceTest because it currently does now allow one to configure the test container factory. I could probably adjust ResourceTest and open a pull request for that, but I'm busy with a few other projects right now.

[cowtowncoder]

One thing I do not understand here is writing of the config file -- couldn't one just work with Config objects? Or maybe this was due to earlier inability to change values (properties were private, no setters). So approach can probably be simplified in this part.

[andreisavu]

Where can I find an example of how to use Config objects? I had to write the config file because that was my only choice at that time.

[cowtowncoder]

I wish I had better example code available, but sub-module "ts-test-cluster" of

https://github.com/FasterXML/TransiStore

has full setup that spins up 4 instances of the store server.

The relevant section for starting up is this (in StoreForTests)

public static StoreForTests createTestService(BasicTSServiceConfigForDW config,
        TimeMasterForClusterTesting timeMaster, boolean fullInit)
    throws Exception
{
    StoreForTests service = new StoreForTests(timeMaster, fullInit);
    Bootstrap<BasicTSServiceConfigForDW> bootstrap = new Bootstrap<BasicTSServiceConfigForDW>(service);
    final Environment environment = new Environment("TestService", config,
            new ObjectMapperFactory(), new Validator());
    bootstrap.runWithBundles(config, environment);
    service.run(config, environment);
    final Server server = new ServerFactory(config.getHttpConfiguration(),
            "StoreForTests").buildServer(environment);
    service._jettyServer = server;
    return service;
}

where BasicTSServiceConfigForDW extends basic DropWizard Configuration.

Caller than just does something like:

BasicTSServiceConfigForDW config = new BasicTSServiceConfigForDW();
config.getHttpConfiguration().setPort(9090); // override http port
// and so on

[jdamick]

I've done something similar and would find this extremely useful as well if it was built in, but having the option to either create the config obj or to use an existing configure file would be helpful.

[codahale]

I don't have any interest in maintaining this, sorry.

[btiernay]

@codahale No offense but this is the type of remark that lead me to switch to Spring Boot. I respect the great work you've done with DW but I'm getting the sense that what you deem useful and what the community deems useful are generally quite different.