[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [jakartaee-platform-dev] Pattern for designating certain standlone TCK tests as EE-only?
|
On 8/17/21 11:32 AM, Scott Kurz wrote:
In batch we have some function
(integration with JTA global transactions) required in
EE-only.
As we continue to phase out the
Batch portion of the Platform TCK and use our Batch standalone
TCK instead, how do we "guard" the tests accordingly?
Users currently use the Platform TCK `keywords` to opt into
different technologies via options like {javaee,
javaee_web_profile, javaee_optional, javaee_web_profile_optional }
specified via command line options passed into Ant. I have not
had the pleasure of running the standalone Batch TCK yet but
assume that currently just assumes it is doing an "SE run", sound
right?
Is there already a pattern for
dealing with this in other component TCKs?
As Scott Stark mentioned, the CDI TCK already does
deal with this (via TestNG).
For JUnit5,
https://junit.org/junit5/docs/5.7.1/api/org.junit.platform.launcher/org/junit/platform/launcher/LauncherDiscoveryRequest.html
might help to influence whether the SE or EE tests are
discovered and run.
Some ideas:
1. Test for EE and
run/ignore/no-op accordingly
Do a JNDI lookup of java:comp/UserTransaction and if it fails dynamically ignore
all the test methods in the class
(a slight variant would be to
pass the tests rather than ignoring.
2. Add SE vs EE config
Add some other external
switch/config so that the user executing the TCK has to
explicitly choose if they're doing an "SE run" or an "EE run"
... with the JTA tests only getting executed in EE.
3. Move the EE set of tests
into the platform TCK
Would this be everything under the
https://github.com/eclipse-ee4j/batch-tck/tree/master/com.ibm.jbatch.tck/src/main/java/com/ibm/jbatch/tck/tests/ee
folder and everything else needed from Batch would be available as
a Maven artifact?
---
Does 1. seem like an allowed
approach, given the overall Eclipse / Jakarta specification
rules?
Do we need to worry about a
case where the java:comp/UserTransaction
lookup fails on a
supposed EE-compatible implementation, thereby ignoring tests
which should have been executed?
Say one had a modular
implementation where transactions or even JNDI had to be
optionally activated/enabled.... is there a concern that this
implementation could certify against Batch and go on to
certify against all components in the platform but without
ever having run the "Batch EE" tests?
I think that's probably enough
detail to help route this conversation to where it needs to
happen.. either the right list or maybe the monthly call, so
please let me know.
Thank you,
------------------------------------------------------
Scott Kurz
WebSphere / Open Liberty Batch and Developer Experience
skurz@xxxxxxxxxx
--------------------------------------------------------
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev