[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [jakartaee-tck-dev] [data-dev] New Tools and Challenges of Creating Modern TCK on Persistence Layer
|
On 27. 04. 23 23:06, Olivier Lamy
wrote:
Hi,
I Agree too for those same reasons.
We already have a standard way to deploy to containers via
Arquillian suite.
Let's not reinvent the wheel :)
And I'm using testcontainer a lot but in this particular
case I definitely agree with all the reasons above.
At the end of the day, testcontainer can still be used by
the Arquillian container impl? (just write an Arquillian GF
using testcontainer)
I already had this, quite easy.
If I look at the case of Servlet TCK with Jetty, this will
be a loss of productivity and speed.
Because the Aquillian Jetty is using an embedded Jetty
which means it's only one jvm start (e.g everything runs
within the same jvm) and it means I can start/debug the tests
with IntelliJ very easily.
Using a tool such testcontainer will make this more
complicated to debug with a remote started container.
It is not so bad, you just map the port to a concrete value, set
this in Eclipse and hit debug. (project - random with most of
dependencies, so I can see sources).
Yeah, with Jetty it is much easier, I don't need any settings (if
I am not using a different debug port). I can do that even with
TestContainers, if I would use 9009 and had it free on localhost.

--
David Matejcek | OmniFish
david.matejcek@xxxxxxxxxxx
Hello All,
I am hesitant to agree with this direction.
I've heard many times that Arquillian is old and
not "modern" but it's more modern than the Vehicle
approach of the current platform TCK.
Additionally, Arquillian has already solved many of
the roadblocks in place when writing tests that need
to run on a Jakarta EE platform.
I've used TestContainers extensively and here are
the roadblocks that Arquillian has solved that we'd
have to solve if we decided to switch to
TestContainers:
- TestContainers doesn't have a standard Interface
for application server containers.
- We would have to create one, and every Jakarta
EE platform would need to implement it (similar
to how every platform server has an Arquillian
implementation).
- We would have to create a library similar to
ShrinkWrap that would allow us to programmatically
create applications and deploy them to the test
container.
- We would have to create a set of protocol
libraries that also get deployed to the test
container so that tests only have to be written
once but can be tested either using:
- Core profile: using REST
- Web profile: using Servlet
- We would have to figure out a way to distinguish
between tests that need to run on the client
system vs. inside the container.
- We would have to create a deployment library
that can be extended by those running the TCK to
allow for one-off customizations to the
application before it is deployed.
- For example, the Concurrency TCK allows
vendors to add custom *-ejb-jar.xml
files to artifacts before they are deployed.
- Finally, all of this would need to be worked
both into the Junit5 lifecycle and the
TestContainer lifecycle.
I honestly think the work I've done on the
Jakarta Data TCK shows how simple using Arquillian
can be and I even had to figure out a way to make
that TCK run both in a Standalone mode and on
different Jakarta EE profiles (core / web).
I don't think it is feasible to make the jump
from Vehicles to TestContainers for Jakarta EE 11.
I also worry that using TestContainers will raise
the complexity of running the TCK for vendors as
opposed to Arquillian.
Thank you,
Kyle Jon Aure
_______________________________________________
jakartaee-tck-dev mailing list
jakartaee-tck-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-tck-dev
--
_______________________________________________
jakartaee-tck-dev mailing list
jakartaee-tck-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-tck-dev