Adding "Test-Containers" to the extras repo?

[chrisdutz]

Hi all ...

While thinking on how we can improve the testability of our drivers in various languages and while brainstorming on how I can eliminate the issues with testing against the Milo Testserver, I started digging into TestContainers as potential solution. Here we could create a Docker container, that is automatically started for being used in our Integration-Tests.

This would have the benefit of us being able to setup and configure a reference-machine, that we can fire tests against. And the good thing would be, that we only have to do this once. Right now it would be challenging to run Milo in order to test the Go OPC-UA driver. Using test-containers would let us use whatever type of server we want (If there's an implementation of a Server written in C ... just fire up the container and use that in the Java testsuite).

So that got me thinking: Where do I move the code? So for OPC-UA I see a TestMiloServer which is used to start the Milo Server in the current testsuite. Technically I could probably tell the jar plugin to package the test-jar aswell and I could probably just use this to deploy in Docker, but that sounds ugly.

Moving it into a separate module, would add more modules that we need to maintain (and update).

Now I thought: If we defined pre-defined Docker containers in our new extras repository, we could release them (and only release them whenever we need to) but also users could probably just fire up one of these and start playing with PLC4X.

So I am currently in strong favor of adding a new section to the plc4x-extras repo which we use to define Docker containers that we then can use in our testsuite.

What do you folks think?

Chris

[ottobackwards]

I agree with this.
I think I mentioned a long time ago that I use docker / compose to run simulated networks with simulators for different protocols to test clients against, this works well if you have the simulator.

[splatch]

Test containers have support for on-demand creation of containers, so they can be built on the fly as test goes. It slows down process, but avoids necessity to release containers prior test.
Obviously it locks down container to just one language and limits its portability, but if container is for our own use during test phase, it doesn't have get public. That's as far I remember trouble with Milo stuff, that we should abstain from re-publish non EPL stuff.