We have a spring application that runs in one of a few ways, depending on a specific property, which has to be one of a small set of values. When the application starts up, this property gets passed to a factory, which then builds slightly different bean implementations depending on it.
I’d like to write an integration test for the functionality this controls to ensure it works when the property is set to various values; so it needs to run one test with the property set to 1, one test with the property set to 2, etc. Each test needs to set the property as required, and then reload the configuration so that everything is reconfigured correctly.
Getting the context and manually refreshing it in each test seems simple enough, but how can I inject these different properties in the tests at runtime to control this? Is there any better way of organising this sort of configuration?
I eventually found a way to actually do this directly. It’s slightly messy, but not actually too bad.
Originally, the tests were being run with an @ContextConfiguration, and then later initialised with
new TestContextManager(getClass()).prepareTestInstance(this);in the @Before (initialised separately so we could use runners other than the Spring one).I extended this to first register a text execution listener which just grabbed the TestContext into the test itself whenever one became available:
The test itself then injects a property into a custom PropertyPlaceholderConfigurer (extremely simple: overrides resolvePlaceholder, calls super.resolvePlaceholder unless you’ve previously explicitly set the property) once it knows what the property’s actual value is (not until the actual test, unfortunately), and calls:
which makes the TestContext rebuild the application context, now using the newly changed property value.
Finally, you then need to remember to reset the property between tests, and probably mark the whole class as @DirtiesContext, to stop it interfering with your other tests.