Thanks Claus! That's a good point and I haven't written much - other than
the pre 3.7 release doc update - about it.

Let me show what a conversion from the camel-testcontainer to
camel-test-infra would look like ... I am using the work on camel-nats as
an example and we can compare how the base test class for nats changed
between 3.6.x [1] and 3.7.x [2].

The first conversion step is to replace the camel-testcontainer
dependencies [3] with the ones from the test-infra module [4]. Then, it's
necessary to replace the container handling code and the old base class [5]
with the service provided in the module. It's important to register it as a
JUnit 5 extension [6]. Then, we replace the ContainerAwareTestSupport (and
similar classes from other camel-testcontainer modules) with
CamelTestSupport (or the spring based one) as it is not needed anymore.

The next step is to make sure that addresses (URLs, hostnames, ports, etc)
and resources (usernames, passwords, tokens, etc) referenced during the
test execution, use the test-infra services. This may differ according to
each service. Replacing the call to get the service URL [7] with the one
provided by the test infra service [8] is a good example of this.

This was the bulk of the work for the Camel code base.

There are a few other cases which may require extra attention/work. They
were not so common, but to highlight:

- It may be necessary to adjust the variables used in simple language [9]
so that they match the property format used in the test infra service [10]
(as was the case for camel-consul).
- There are some cases where the container instance requires extra
customization [11]. The code still benefits from the test-infra approach,
but this may be very specific to the test scenario [12] .

All in all, it's not a significantly complicated task but it's not a
drop-in replacement either.

I am linking here to the PR which I submitted for the camel-nats conversion
[13] just in case I missed anything. At first sight it may look more
complicated than what I said, but that's because it also contains the
test-infra code for Nats.

1.
https://github.com/apache/camel/blob/camel-3.6.0/components/camel-nats/src/test/java/org/apache/camel/component/nats/NatsTestSupport.java
2.
https://github.com/apache/camel/blob/camel-3.7.0/components/camel-nats/src/test/java/org/apache/camel/component/nats/NatsTestSupport.java
3.
https://github.com/apache/camel/blob/camel-3.6.0/components/camel-nats/pom.xml#L59-L63
4.
https://github.com/apache/camel/blob/camel-3.7.0/components/camel-nats/pom.xml#L61-L75
5.
https://github.com/apache/camel/blob/camel-3.6.0/components/camel-nats/src/test/java/org/apache/camel/component/nats/NatsTestSupport.java#L24-L45
6.
https://github.com/apache/camel/blob/camel-3.7.0/components/camel-nats/src/test/java/org/apache/camel/component/nats/NatsTestSupport.java#L25-L27
7.
https://github.com/apache/camel/blob/camel-3.6.0/components/camel-nats/src/test/java/org/apache/camel/component/nats/NatsAuthConsumerLoadTest.java#L38
8.
https://github.com/apache/camel/blob/camel-3.7.0/components/camel-nats/src/test/java/org/apache/camel/component/nats/NatsAuthConsumerLoadTest.java#L38
9.
https://github.com/apache/camel/blob/camel-3.6.0/components/camel-consul/src/test/resources/org/apache/camel/component/consul/cloud/SpringConsulRibbonServiceCallRouteTest.xml#L36
10.
https://github.com/apache/camel/blob/camel-3.7.0/components/camel-consul/src/test/resources/org/apache/camel/component/consul/cloud/SpringConsulRibbonServiceCallRouteTest.xml#L36
11.
https://github.com/apache/camel/blob/camel-3.6.0/components/camel-pg-replication-slot/src/test/java/org/apache/camel/component/pg/replication/slot/integration/PgReplicationTestSupport.java#L31
12.
https://github.com/apache/camel/blob/camel-3.7.0/components/camel-pg-replication-slot/src/test/java/org/apache/camel/component/pg/replication/slot/integration/PgReplicationTestSupport.java#L31
13. https://github.com/apache/camel/pull/4706/files

On Tue, Jan 5, 2021 at 10:36 AM Claus Ibsen <claus.ib...@gmail.com> wrote:

> Hi Otavia
>
> Great work.
>
> Can you maybe tell a bit about what if an end user have used
> camel-testcontainers-junit5 to do his/her own container testing with
> Camel (for example to use their own container image, or for example a
> database container or something). How would they do that today with
> the test infra?
>
>
> On Tue, Jan 5, 2021 at 9:37 AM Otavio Rodolfo Piske
> <angusyo...@gmail.com> wrote:
> >
> > Hello,
> >
> > as of 3.7.x, all the test infrastructure code that we had was converted
> to
> > use the test-infra modules.
> >
> > This brings several benefits for in terms of maintenance for the test
> code:
> > - we can share more easily, among the sub-projects, the code handling the
> > test infrastructure. For example: setting up and running message brokers,
> > databases, cloud simulation containers, etc.
> > - we "outsource" the management of the resources to JUnit 5 and let it
> > handle the lifecycle, setup, etc ... thus simplifying the test code.
> > - we can separate the interface from implementation. This allows us and
> > colleagues running and testing the Camel code to run integration and
> > interoperability tests more easily. For example, it makes it possible to
> > run the same tests against remote instances of the said infrastructure.
> > This is very handy for AWS tests, for example, where we can switch to run
> > the tests from Localstack containers to an actual AWS instance by simply
> > adjusting the test parameters. It still uses testcontainers under the
> hood,
> > but it is abstracted from the test code.
> >
> > As result of this migration, the code in the following components has
> > become unused within Camel:
> > - camel-testcontainers
> > - camel-testcontainers-junit5
> > - camel-testcontainers-spring
> > - camel-testcontainers-spring-junit5
> >
> > I'd like to propose deprecating these components, starting with 3.8 and
> > then removing them before we release the next LTS.
> >
> > Therefore, I'd like to gather feedback from the community about usage of
> > those modules, thoughts on the idea and if any roadblock remains.
> >
> > Kind regards
> > --
> > Otavio R. Piske
> > http://orpiske.net
>
>
>
> --
> Claus Ibsen
> -----------------
> http://davsclaus.com @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2
>


-- 
Otavio R. Piske
http://orpiske.net

Reply via email to