Re: [jakartaee-platform-dev] Pattern for designating certain standlone T

[Emily Jiang <emijiang6@xxxxxxxxxxxxxx>]

Personally, I think having the integration tests staying in the corresponding repo is very important as it is much easier to manage the tests in the standalone TCKs. I think the platform TCKs should be  bare minimum by ensuring that the specs can work together and other additional statements from platform spec. For any domain specific tests, they should be placed under the individual repo. In this way, when updating any SPIs/APIs, these tests would be updated at the same time. If there are some problems, it would be spotted way earlier.

my 2cents.

Emily

On Tue, Aug 17, 2021 at 4:49 PM Scott Stark <starksm64@xxxxxxxxx> wrote:

What CDI does is to group tests into those that apply to the various platform levels discussed in the spec using TestNG groups. The TCK setup instructions describe the groups that can be added to the surefire excludedGroups config property when running something other than the full platform set of tests. CDI does have a "javaee-full" group for the scenario you are describing.

On Aug 17, 2021 at 10:32:13 AM, Scott Kurz <skurz@xxxxxxxxxx> 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?
Is there already a pattern for dealing with this in other component TCKs?

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
---

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

_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev

--

Thanks
Emily