0

Scenario: Each time I run a Java batch job for testing all the configuration and bootstrap applications need to load. This includes logging, hibernate type registration, global properties etc. This can take up to 3 minutes and if I'm busy iterating different tests and run 10 batch jobs this can waste 30 minutes. Normally this is all contained within a Websphere server but that is way too heavy to restart and re-upload ears for testing purposes.

So far I've looked at Sockets and RMI as options to put the configuration in. For example an RMI server providing configuration as a singleton instance that my tests running in separate JVMs can access. I'm not convinced this is the best way as there is poor documentation on these methods and there seems to be problems getting all dependencies on the classpath for RMI (this application is broken into at least 20 projects).

Is there any best practices for making a configuration stack available to unit tests that can be accesses by separate JVMs? Each time you start a new jUnit test it is ran in a separate JVM and will normally have to create all the configuration every time, I want to run the configuration once and make it available to all unit tests.

JesseBoyd
  • 1,022
  • 1
  • 13
  • 18
  • I don't see how that will help. Reading from a server isn't faster than reading from the file system, if that's where the configuration presently is. The issue is generating the configuration less often, which just just a change to your test sequences.. – user207421 Jun 13 '19 at 23:38
  • loading the configuration into memory takes up to 3 minutes and currently only available to one JVM. Running the next test takes another 3 minutes to load the configuration. Therefore I'm looking for a cross JVM process that can be loaded ONCE and then shared with seperate tests. – JesseBoyd Jun 15 '19 at 00:20
  • *Why* does it take three minutes? This is the problem to solve. And what makes you think a 'cross JVM process' will be quicker? – user207421 Jun 15 '19 at 23:15

0 Answers0