Re: [jakartaee-platform-dev] TCK tests in the same repo as API andSpec

[Emily Jiang <emijiang6@xxxxxxxxxxxxxx>]

Hi Dimtry,

The general guidance in MP is to use TestNG as Junit has some issues working with Arquillian. Until the issue is resolved, we will stay with TestNG. Having said that, in MicroProfile, we plan to revisit this area on which one to go with in the long run.

Thanks

Emily

On Wed, Feb 5, 2020 at 8:51 PM <dmitry.kornilov@xxxxxxxxxx> wrote:

If I remember well MicroProfile TCKs are not consistent with frameworks they use. Some of them are TestNG, some of them are JUnit. I think we all agree that It’s what we want to avoid. IMO, the best way to accomplish it is to create a TCK parent pom, define all dependencies there and recommend all projects to use it. We can place in the same repository where EE4J parent pom is.

 

-- Dmitry

 

From: jakartaee-platform-dev-bounces@xxxxxxxxxxx <jakartaee-platform-dev-bounces@xxxxxxxxxxx> On Behalf Of arjan tijms
Sent: Wednesday, February 5, 2020 9:41 PM
To: jakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
Subject: Re: [jakartaee-platform-dev] TCK tests in the same repo as API andSpec

 

Hi,

 

On Wed, Feb 5, 2020 at 9:25 PM Andy Guibert <andy.guibert@xxxxxxxxx> wrote:

B) Migrate TCK tests to the spec repo, as I have done with JSON-B here: https://github.com/eclipse-ee4j/jsonb-api/pull/221

 

One thing I'd love to see there is a consistent use of the Arquillian container profile, or even have a strong recommendation Arquillian is used. 

 

Additionally, though I'm not in any way a fan, all of MP (if I'm not mistaken) as well of CDI, BeanValidation and Batch use TestNG, not Junit. Perhaps it's best to have some consistency there as well.

 

I remember that in Java EE 7 samples we had the door open for "whatever" and essentially every test used another combination of technologies. The permutations must have been a dozen or more.

 

As test engineer it's not unlikely you have to jump between tests for different but related APIs., E.g. for Jakarta Faces I'd jump between Jakarta Servlet, Jakarta _expression_ Language, Jakarta WebSocket, and Jakarta Security. Having to adjust mindset every time would not be productive, especially since often there's no reason for a project to use technology X over technology Y other than that person A just started to use X and not Y.

 

As for the Arquillian and consistent use of profiles; as a Jakarta EE vendor I'd hate to write and maintain adapters and porting kits for every API in Jakarta EE. Ideally I provide 1 implementation to run all of the APIs that make up the full platform.

 

Kind regards,

Arjan Tijms

 

 

 

 

 

 

 

 

 

 

_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev

--

Thanks
Emily