Better name for @DockerRequired

[rhusar]

Let's find a better name for @DockerRequired. We in reality require any containerization software that is compatible with Testcontainers (their explicit wording 'Docker-API compatible container runtime'), thus including podman. Random ideas:

• RequiresContainerRuntime
• ContainerRuntimeRequired
• ContainersRequired
• RequiresContainers
• ContainerizationRequired
• RequiresContainerization
• RequiresDockerAPICompatibleRuntime
• CompatibleContainerRuntimeRequired
• ContainerEnvironmentRequired
• ContainerRuntimeCompatible
• OpenContainersRequired

[jamezp]

I've got a new suggestion of @RequiresTestcontainers to make it more generic and really what this is about.

[rhusar]

I've got a new suggestion of @RequiresTestcontainers to make it more generic and really what this is about.

I like the that, but in reality is checks for docker/podman runtime? :-) Wouldn't that make it a bit of a misnomer?

[jamezp]

It does, but that's an implementation detail. We only check if it exists because that's what Testcontainers requires. If for whatever reason they switched to something else, it wouldn't make much sense. The idea is we're saying "Something in this test requires Testcontainers".

[jasondlee]

It does, but that's an implementation detail. We only check if it exists because that's what Testcontainers requires. If for whatever reason they switched to something else, it wouldn't make much sense. The idea is we're saying "Something in this test requires Testcontainers".

That's why I like (d?) @ContainerRequired. It doesn't imply or require a specific containerization engine.

[jamezp]

I'd be a +1 for @ContainerRequired too if we don't like @RequiresTestcontainers. The term "container" is overloaded, but I don't have a better suggestion other than explicitly saying "Testcontainers".

I do also like @OpenContainersRequired given that is the initiative name https://opencontainers.org/

[rhusar]

@jamezp @jasondlee Do we have stronger feeling about this since November? I think my excitement is now distilled to "anything without a proprietary company name" is sufficient to me.

We also toyed with the idea that this might not even be required, right? @jamezp does that still make sense?

[jamezp]

I think we do need the annotation. There's not a good way to handle a scenario where something like a WildFly Arquillian ServerSetupTask requires a container, but the test doesn't use the specific container. By annotating the test itself we can fail or skip early. We could see unpredictable errors if both the test and the ServerSetupTask are not both annotated. The test itself would still run, but the SST would either be skipped or fail.

As for the name... ...I'm not sure. In some ways I like @OpenContainersRequire only because that is the name of the initiative that Testcontainers, Docker and podman are based on. That said, @ContainerRequired seems fine too. I've got no strong preference between those two. The latter is shorter though :)