Hello,

I was talking to Luca a while ago where he pointed me to this discussion on
StackOverflow [1]. This reminded me that last year I raised this suggestion
about deprecating some of the camel-testcontainers components. I think we
have migrated all of our code to test-infra by now.

I am wondering how the community feels about removing those components in
favor of the test-infra components?

My idea here is to execute the following plan:

1. Review and move the development documentation [2] to the website and
make it more visible to the end users.
2. Remove the components for 3.16.0 (or do you prefer 3.17.0?)
3. Write a blog post about it, linking to the new test infra documentation

If you don't agree, then I think we can rollback marking the components as
deprecated and keep test-infra for internal use only.

Links:
1.
https://stackoverflow.com/questions/71027100/is-camel-testcontainers-deprecated-what-replaces-it
2. Test infra development doc:
https://github.com/apache/camel/tree/camel-3.15.0/test-infra

Any thoughts?

Kind regards

On Thu, Jan 14, 2021 at 9:24 AM Otavio Rodolfo Piske <angusyo...@gmail.com>
wrote:

> Thanks Alex, Andrea and Claus for the feedback.
>
> If I understand it correctly. It should be OK to mark the classes as
> deprecated.
>
> I am going to extend the test infra [1] documentation and will send a PR
> for review, with some classes I think could be marked deprecated as part of
> this.
>
> 1. https://github.com/apache/camel/tree/master/test-infra
>
> Kind regards
>
> On Fri, Jan 8, 2021 at 10:00 AM Alexandre Gallice <aldettin...@gmail.com>
> wrote:
>
>> I see no show stopper to deprecation.
>> Some camel-testcontainers-junit5 users out in the community might enjoy a
>> short and concise migration guide with explanation from Otavio above.
>>
>>
>> On Fri, Jan 8, 2021 at 9:00 AM Andrea Cosentino <anco...@gmail.com>
>> wrote:
>>
>> > I'm ok with deprecating the classes :-)
>> >
>> > Il ven 8 gen 2021, 08:48 Otavio Rodolfo Piske <angusyo...@gmail.com> ha
>> > scritto:
>> >
>> > > Just to clarify one point, because I don't want to sound pushy and I
>> may
>> > > have misunderstood you.
>> > >
>> > > I was originally talking about marking as deprecated and suggested a
>> > > timeline for removing it. I interpreted your reply as a comment for
>> both
>> > > (deprecating and removing).
>> > >
>> > > If you commented about the deprecation (ie: marking the classes as
>> > > deprecated), then, please ignore my reply: I got your point.
>> > >
>> > >
>> > >
>> > >
>> > > On Fri, Jan 8, 2021 at 8:34 AM Otavio Rodolfo Piske <
>> > angusyo...@gmail.com>
>> > > wrote:
>> > >
>> > > > Thanks Andrea.
>> > > >
>> > > > I was thinking: how about we only mark the classes as deprecated for
>> > now?
>> > > > Therefore we start to gently encourage users to look at test-infra.
>> > > >
>> > > > In my original email I mentioned removing them before the next LTS,
>> > but,
>> > > > indeed, this may be way too soon.
>> > > >
>> > > > Kind regards
>> > > >
>> > > > On Thu, Jan 7, 2021 at 2:49 PM Andrea Cosentino <anco...@gmail.com>
>> > > wrote:
>> > > >
>> > > >> I use test-infra stuff even at ckc but before deprecating the
>> > > >> testcontainers components I'd like to have feedback from existing
>> > > users..
>> > > >>
>> > > >> Il mar 5 gen 2021, 11:36 Otavio Rodolfo Piske <
>> angusyo...@gmail.com>
>> > ha
>> > > >> scritto:
>> > > >>
>> > > >> > 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
>> > > >> >
>> > > >>
>> > > >
>> > > >
>> > > > --
>> > > > Otavio R. Piske
>> > > > http://orpiske.net
>> > > >
>> > >
>> > >
>> > > --
>> > > Otavio R. Piske
>> > > http://orpiske.net
>> > >
>> >
>>
>
>
> --
> Otavio R. Piske
> http://orpiske.net
>


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

Reply via email to