docker-compose-rule
docker-compose-rule copied to clipboard
How to specify docker-compose file for each @Test method
Hello everyone, i have question regarding on now to specify docker-compose file for each @Test method. Basically, I have requirements where each test method should start with different docker-compose file. Is this possible?
Currently I have following solution which is breaking @Rule convention.
@Test
public void testTest1() throws IOException, InterruptedException {
dockerComposeRule = DockerComposeRule.builder()
.file(DOCKER_COMPOSE_ROOT+"docker-compose-test1.yml")
.machine(dockerMachine)
.saveLogsTo("target/dockerLogs/dockerComposeRuleTest/test1")
.build();
dockerComposeRule.before();
}
@Test
public void testTest2() throws IOException, InterruptedException {
dockerComposeRule = DockerComposeRule.builder()
.file(DOCKER_COMPOSE_ROOT+"docker-compose-test2.yml")
.machine(dockerMachine)
.skipShutdown(true)
.saveLogsTo("target/dockerLogs/test2")
.build();
dockerComposeRule.before();
}
Hi Akram,
Unfortunately we're pretty limited in what we can offer as there's no clean syntax for passing test-specific parameters to rules in JUnit.
@akrambek I'd say that's a reasonable way to do it. While the code doesn't use rules in a idiomatic way, I don't think your intent is an idiomatic way to use rules either.
Another approach is to have 1 test per file and use rules in a normal way.
Thanks @chrisalice @joelea for the prompt answer I am considering to create custom Annotation if it is possible.
It should be possible to enhance DockerComposeRule to work in conjunction with annotations to allow the builder configuration parameters (file, machine, etc) to be specified as annotations on each test method. See K3poRule (especially its apply method) which uses a similar technique to support @script and @scriptProperty annotations on test methods so they can use the rule to configure how k3po (a network protocol testing robot) is run for each test.
That sounds like an interesting idea.
One worry I have is whether there's going to be a consistent set of things people want to differ across individual tests in one class. If there are a small proportion of fields people want to modify then having a few annotations to deal with those cases might make sense.
However, I want to avoid exposing the whole suite of configuration via interfaces as at that point it makes more sense to generate the rule individually for each test method and call before
/after
by hand.
+1 for adding annotations.I think this is needed and it will be a nice improvement