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
Emily/Scott,

For this decision I see JUnit vs. TestNG as an "implementation detail" that does not need to be discussed yet -- they are both pretty similar and it doesn't make a big difference at a high level.
Before we discuss things like JUnit vs. TestNG, I want to focus on getting agreement on the overall concept: the ability for specs to make their TCKs standalone and use more modern/familiar tools in the process.


Bill/Kevin,

The project plan you describe sounds very "waterfall" to me. What I had in mind was more along the lines of starting with one spec (JSON-B) trying it out for a release, and then collecting feedback and iterating on it.
Dmitry said that this would not effect Jakarta EE 9, but the JSON-B stuff is ready to go and I think it would be good to "test drive" the process for Jakarta EE 9 so I can take concrete feedback from that experience and use it to define a broader process for EE 10.
What do you think?


On Wed, Mar 11, 2020 at 9:04 AM Scott Kurz <skurz@xxxxxxxxxx> wrote:

So as we're trying to launch in as few different directions as possible, it'd help to understand the details of the JUnit + Arquillian issues: E.g. what piece of the MP TCKs surface these issues, and on the flip side how is the JSON-B TCK rework able to avoid them?

Emily, do you have any pointers?

Thanks,
------------------------------------------------------
Scott Kurz
WebSphere Batch and Developer Experience
skurz@xxxxxxxxxx
--------------------------------------------------------

Inactive hide details for Emily Jiang ---03/11/2020 07:14:10 AM---Hi Dimtry, The general guidance in MP is to use TestNG as JunEmily Jiang ---03/11/2020 07:14:10 AM---Hi Dimtry, The general guidance in MP is to use TestNG as Junit has some issues

From: Emily Jiang <emijiang6@xxxxxxxxxxxxxx>
To: jakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
Date: 03/11/2020 07:14 AM
Subject: [EXTERNAL] Re: [jakartaee-platform-dev] TCK tests in the same repo as API andSpec
Sent by: jakartaee-platform-dev-bounces@xxxxxxxxxxx




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

Back to the top