Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakartaee-platform-dev] TCK tests in the same repo as API andSpec

Right now we have 2 types of TCKs:
A) CDI and BeanVal use Arquillian+TestNG, and produce their TCKs as maven dependencies
B) All other specs use JavaTest

I'm proposing to make a 3rd type of TCK (very similar to A) that uses Arquillian+JUnit.
However, I don't really care what test framework gets used to run the TCKs, the main items I care about as a spec developer are:
1) API/spec/TCK all in one repo
2) Implementations (standalone lib or app server) can _easily_ pull in and run the TCKs as a Maven Dependency and doing `mvn test` or `mvn verify`

This is what MicroProfile has done and the model works very well. 

Also, I'm not suggesting we mandate _all_ specs migrate to this way (or require all specs to do anything). Rather, I'm suggesting that we tolerate specs to migrate to the way CDI/BeanVal does it (except using JUnit instead of TestNG preferably). 

On Thu, Feb 6, 2020 at 6:41 PM Bill Shannon <bill.shannon@xxxxxxxxxx> wrote:
It's very simple right now, essentially all TCKs are using JavaTest as the framework.  If you want them to convert to a different framework, maybe provide some tools to help with the conversion?  But I don't think it's all that simple.  If you want to support javaTest plus one other more common framework such as JUnit, just allow all the new tests for that TCK to be written in JUnit.  I'm still hoping for a common test runner that will run both JavaTest and JUnit tests.

Kevin Sutter wrote on 2/5/20 1:06 PM:
You are correct that MP is not consistent in this model, but that doesn't mean it's the right process to follow...  :-)  Seriously, I would like to see more consistency.  Allowing multiple test frameworks to be used across the whole Jakarta EE platform could be troublesome in the long run.  I like the idea of defining the proper dependencies and configuration in the parent pom and require/recommend all projects to use it.

---------------------------------------------------
Kevin Sutter
STSM, MicroProfile and Jakarta EE architect @ IBM
e-mail:  sutter@xxxxxxxxxx     Twitter:  @kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)    
LinkedIn:
https://www.linkedin.com/in/kevinwsutter



From:        <dmitry.kornilov@xxxxxxxxxx>
To:        "'jakartaee-platform developer discussions'" <jakartaee-platform-dev@xxxxxxxxxxx>
Date:        02/05/2020 14:51
Subject:        [EXTERNAL] Re: [jakartaee-platform-dev] TCK tests in the same repo as        API        andSpec
Sent by:        jakartaee-platform-dev-bounces@xxxxxxxxxxx



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



_______________________________________________
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

_______________________________________________
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

Back to the top