Shutting down server after test suite

210 views
Skip to first unread message

Ben Chambers

unread,
Oct 14, 2009, 5:20:58 PM10/14/09
to guiceberry-users
If you have GuiceBerry tests that use GuiceBerryEnvMain and the run
method to start a server up, is there any clean way to shut the
servers down after all the tests have been run?

Robert Dionne

unread,
Oct 14, 2009, 8:27:04 PM10/14/09
to guiceber...@googlegroups.com
You could add a shutdown hook to the JVM with the following code:

Runtime.getRuntime().addShutdownHook(new Thread() {
  @Override
  public void run() {
    // shut down your server
  }
});

I'm not sure how "clean" this is. If shutting down your server takes too long, the JVM complains that the shutdown hook timed out.

I think there should be another callback added to GuiceBerryEnvMain that runs after all tests execute, so you could safely shutdown your server.

-Robert

Luiz-Otavio Zorzella

unread,
Oct 15, 2009, 12:38:41 PM10/15/09
to guiceber...@googlegroups.com
A couple of things:

1. GuiceBerry itself cannot know when all your tests are done, for
JUnit does not have that concept. Note that GuiceBerry does not
participate at all in the running of the test (it gets out of the way
as soon as it @Injects the test class).

2. In most cases (I've seen), the simple JVM exit itself (without any
hook) will suffice -- if the JVM dies, all its java allocated things
die as well.

3. In most of the remaining cases, the JVM shutdown hook proposed
solution should hopefully work (I use a shutdown hook, myself, to
"close" Selenium, for example).

4. In the rare circumstances where all else fails, there's a still a
way to do it in JUnit. I'm not going to claim it's neat, and it has
problems of its own (see below), but it's what JUnit provides. The
idea is if you are the one to construct the test suite, you can add as
the very last test to this suite a test that goes something like:

@Inject server;

public void testShutDown() {
server.shutdown();
}

The problem with this approach, of course, is that you must run the
entire suite, never the individual tests or test cases, so I don't
necessarily see it as a good solution to the exact problem you
described. But it can be useful if you have, say, two GBEs that
"conflict" with each other wrt some static state, but still want a
single test suite that runs all tests -- in that case, that suite
should run all tests in the first GBE, then use this trick to run a
test that clears out the static junk, then run all tests in the second
GBE.

I hope that made sense.

Z
Reply all
Reply to author
Forward
0 new messages