Closed jasondlee closed 4 months ago
I have a slight preference for an array so the failIfNoDocker
would only need to be defined once. That said, I can see the attraction for a repeatable annotation as well. Possibly we could do both if that would make any sense.
Taking an array as a parameter of @TestContainer
is not enough.
To customize the containers, for example, I want to test against Glassfish, Postgres, Redis, and ArtemisMQ, and I want to set the some details of connection info for these containers, and how to process?
I prefer to reuse the existing facilities (Testcontainers
and @Container
) provided by testcontainers to customize the container instances freely, see #11
@hantsy This is for a different use-case. There's not reason you cannot use those annotations with Arquillian. However, if you use those you don't really have a need for this project as it is being used for environments where using those annotations is not an option.
If you need a configuration, the idea is you'd just have to extend the class like:
public class SimpleTestContainer extends MockServerContainer {
public SimpleTestContainer() {
super(DockerImageName
.parse("mockserver/mockserver")
.withTag("latest"));
}
}
Then you just reference the SimpleTestContainer
in your annotation.
What I've provided works with repeatable annotation, this seemed more intuitive (or readable) to me.
I'll think also about the array of instances, this should not be much an issue.
What @hantsy mentioned about the customization is also reflected in the PR and even more as in a pure TestContainer approach, I want to use the Arquillian build and deploy a WebArchive (on Wildfly, that's my target platform - in the end also run the test in the container, not running as client. But as said, this is a different use case, not just having multiple container instances in one test
Currently this would only support running as a client. The BeforeClass
happens before we know if it's an in-container or client test, I think.
In either case, if we could find a way to support in-container tests the injected container would not be available for client tests included usage in a ServerSetupTask
.
It's going to take some thought of how we could determine a test is an in-container vs client test before we would be able to support that.
@kifj Explored the example codes in PR https://github.com/arquillian/arquillian-testcontainers/pull/12, the configuration is a little tedious compared to the basic Spring Boot testcontainers support.
@SpringBootTest
@Testcontainers// from testcontainers
class MyTeset {
@Container // from testcontainers
@ServiceConnection // from spring Boot, used to set autoconfiguration properties of conainter service
static AContainer container = ...
}
I'm not sure I completely follow, but we're definitely open to other options. That said, I'm not sure we can re-use the @Testcontainer
annotation. We'd have to re-think how we do this if we want to do that. Currently this happens before the class is created in Arquillian.
I've merged @kifj's PR (thanks, again!). Any further refinements can be done under another issue.
Thanks to all for the input!
Consider making the value of @Testcontainer an array, or making the annotation repeatable so that multiple containers can be managed on a given test.