Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakartaee-tck-dev] [External] : Re: [data-dev] New Tools and Challenges of Creating Modern TCK on Persistence Layer 
On 30.04.2023 9:54, David Matejcek wrote:
Actually this means complexity, because pre/post integration tests are not executed by an editor, so for debugging or running individual tests or blocks of tests you have to prepare the environment manually, run what you want (and be careful to have all endpoints set correctly) and finally stop the server.
I may have misunderstood this comment but wiring tests to particular editor sounds wrong to me. As long as one can run/debug one particular test from the command line, editor should not matter as it is more a matter of how well one knows tools he uses - it is not a goal to force everyone to use "the right editor", right? Speaking of maven - -Dmaven.surefire.debug -Dtest=... or -Dmaven.failsafe.debug -Dit.test=... makes me independent on the editor/IDE as long as it offers the feature to remotely attach to the running process across various projects and regardless of possible pre/post-integration steps in most cases. 

thanks,
--lukas




BUT.
With some design I could use tests and wrap them ie. to JUnit5 extension like I do that with GlassFish integration tests here: 
https://github.com/eclipse-ee4j/glassfish/blob/master/appserver/tests/tck/tck-runner/src/test/java/org/glassfish/main/tests/tck/ant/junit/TckTestExtension.java
https://github.com/eclipse-ee4j/glassfish/blob/master/appserver/tests/tck/tck-runner/src/main/java/org/glassfish/main/tests/tck/ant/TckRunner.java - even with that Ant hell we made it, for partial executions we have this:
https://github.com/eclipse-ee4j/glassfish/blob/master/appserver/tests/tck/tck-runner/src/test/java/org/glassfish/main/tests/tck/ant/tests/CustomITest.java

Or with more complex tests here:
https://github.com/eclipse-ee4j/glassfish/tree/master/appserver/itest-tools/src/main/java/org/glassfish/main/itest/tools
https://github.com/eclipse-ee4j/glassfish/blob/master/appserver/itest-tools/src/test/java/org/glassfish/main/admin/test/tool/StartStopITest.java
https://github.com/eclipse-ee4j/glassfish/blob/master/appserver/tests/admin/tests/src/test/java/org/glassfish/main/admin/test/rest/ApplicationITest.java
https://github.com/eclipse-ee4j/glassfish/blob/master/appserver/tests/admin/tests/src/test/java/org/glassfish/main/admin/test/ClusterITest.java

These tests can be executed from editor too, same as from Maven.

On 28. 04. 23 13:30, Manfred Riem wrote:


What about just

 1. Maven projects for the tests.
 2. Write them as Junit 5 tests.
 3. Failsafe plugin.
 4. Vendor hooks in at pre-integration / post-integration step.

No complexity. Setup as a regular project.

Done!
*From:* jakartaee-tck-dev <jakartaee-tck-dev-bounces@xxxxxxxxxxx> *On Behalf Of *Kyle Aure 
*Sent:* Thursday, April 27, 2023 3:46 PM
*To:* data developer discussions <data-dev@xxxxxxxxxxx>
*Cc:* jakartaee-tck developer discussions <jakartaee-tck-dev@xxxxxxxxxxx>
*Subject:* Re: [jakartaee-tck-dev] [data-dev] New Tools and Challenges of Creating Modern TCK on Persistence Layer 

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: 

 1. 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).

 2. 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.
 3. 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

 4. We would have to figure out a way to distinguish between tests
    that need to run on the client system vs. inside the container.
 5. 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.

 6. 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). 

https://github.com/jakartaee/data/tree/main/tck
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, visithttps://www.eclipse.org/mailman/listinfo/jakartaee-tck-dev



--
David Matejcek | OmniFish
david.matejcek@xxxxxxxxxxx


_______________________________________________
jakartaee-tck-dev mailing list
jakartaee-tck-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/jakartaee-tck-dev__;!!ACWV5N9M2RV99hQ!Mt9FvF66Bi1p9pYaaomjm8oxAb_7a_VRs614l6rJGCs_7nNMyeI3qG7t5k5wFCq5GA9gxE3VJzPpK5_t-3OAZqoiVw5GY3fV$

Back to the top