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