Niclas Hedhman a écrit : > To support this, we really need the internal Docker support to become > official. So, I am removing the "internals" as it only contains the > DockerRule stuff, and that I am moving to core/testsupport. > > With that in testsupport, I am adding testcases to Yeoman generator that > will do a full integration test (i.e. slow) and the combinatorial problem > gets blown out of the water, 1 day to a week, with every other feature > added to double that time. Nevertheless, I think it is worthwhile doing.
For our docker testing infrastructure to work in other projects they will need some build machinery to actually build the required docker images (they are not published to any public docker registry). We could at some point either publish testing images or build machinery (e.g. Polygene Gradle Plugin) but that won't happen in 3.0. I think we should not promote docker based testing from internals in a rush. Plus, since I implemented this testing facility, https://www.testcontainers.org/ appeared and I think we should move to using this instead of our ad-hoc solution at some point. For testing the generated projects, maybe only assembly/activation/passivation would be enough for now ? Or, @Ignore the generated integration tests for the assemblies that require external services.
