Otavio,
The work Kyle is doing is complex because he is intentionally from the start covering all the complexity of being able to run against core and web profiles and platform as well as standalone, using providers
backed by either Jakarta Data or Jakarta Persistence (or other), and even including a way to account for eventual consistency. By doing all this work upfront to ensure completeness of the TCK (and in a way that follows the standards already in place in Jakarta
TCKs), it then becomes very simple to add individual tests. At this point, we should be leveraging what Kyle has already built to work on writing the TCK tests for the scenarios we've identified and identifying additional scenarios to add rather than starting
over with something that starts out simple but only works in standalone and defers the complexity of how/whether it can even be possible to do everything else that is needed (the long list that Kyle enumerates) to run the TCK in the profiles/modes that will
be required to certify a 1.0 release. I think it would be fine if some developers want to invest in trying to come up with a new TCK architecture, but that should happen independently and only after it has been demonstrated to be a workable solution for all
profiles, platform, and standalone, and is centralized in a way so as to make it efficiently consumable by TCKs without duplicating and reinventing everything should it be brought back into individual specification projects to consume.
From:
data-dev <data-dev-bounces@xxxxxxxxxxx> on behalf of Otavio Santana <otaviopolianasantana@xxxxxxxxx>
Date: Friday, April 28, 2023 at 12:32 AM
To: data developer discussions <data-dev@xxxxxxxxxxx>
Cc: jakartaee-tck developer discussions <jakartaee-tck-dev@xxxxxxxxxxx>
Subject: [EXTERNAL] Re: [data-dev] New Tools and Challenges of Creating Modern TCK on Persistence Layer
Thank you, Kyle; you've done a great job on the Data TCK; we could not do it without you! But it keeps the topic that an initial test requires many XML files, and
Java classes set up a hard initial test. When I mentioned TestContainer,
|
This Message Is From an External Sender
|
|
This message came from outside your organization.
|
|
|
Thank you, Kyle; you've done a great job on the Data TCK; we could not do it without you!
But it keeps the topic that an initial test requires many XML files, and Java classes set up a hard initial test.
When I mentioned TestContainer, it was a sample.
We could also use the weld-testing as
inspiration to set a single annotation and all the test works.
I'm focusing on the persistence case, Jakarta Data, and NoSQL, where the focus will be more on database and server integration. Once it belongs to the CDI scope, we can jump to anything else, such as object
creation/destruction, but it may need to be corrected.
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.
_______________________________________________
data-dev mailing list
data-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://accounts.eclipse.org
--
|
