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
One caution that bit many devs at my last $dayjob -- the argument ordering on several assertion calls differ between JUnit and TestNG.  For example:

JUnit:  org.junit.Assert.assertEquals ({type} expected, {type} actual)
JUnit:  org.junit.Assert.assertEquals(String message, {type} expected, {type} actual)

TestNG:  org.testng.Assert.assertEquals({type} actual, {type} expected)
TestNG:  org.testng.Assert.assertEquals({type} actual, {type} expected, String message)

This can lead to misleading fail messages if you use the "wrong" ordering for your test framework, or tests that cannot compile if you use the variants with a message.  Note that TestNG also has "junit" type variants, but you have to remember to do the correct imports.

Within two large code bases (legacy and next-gen), we decided to stick with JUnit in the legacy project -- basically all the tests were using it already, but switch to TestNG in the new project.

Craig McClanahan


On Wed, Feb 5, 2020 at 1:12 PM arjan tijms <arjan.tijms@xxxxxxxxx> wrote:
Hi,

On Wed, Feb 5, 2020 at 10:01 PM Andy Guibert <andy.guibert@xxxxxxxxx> wrote:
Arjan, previously in this thread I proposed that we standardize on JUnit+Arquillian.

I'm personally a bigger fan of JUnit so I would not shed a tear when that was the agreed combination. It just happened to be that all the MP tests I ever looked at all used TestNG. TIL there's also JUnit there. Interesting.

Kind regards,
Arjan




 
I think Arquillian is a must-have technology for modern TCKs (and most vendors already have Arquillian impls), and then JUnit is much more widely used than TestNG therefore I think we should prescribe JUnit (but not force existing specs like BVal and CDI to change).

Dmitry, I think we should not prescribe a parent pom for TCKs because it will force all TCKs to use the same versions of JUnit and Arquillian. Updating the versions in the future would be essentially impossible because it will be difficult to reliably test the matrix of all specs multiplied by all vendor implementations.  As long as we stick to the same technologies across the board, the versions we use are less important (e.g. as a test engineer I don't care if one spec uses Arquillian 1.10 and another spec uses Arquillian 1.11).

On Wed, Feb 5, 2020 at 2:52 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
_______________________________________________
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