[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [jakartaee-tck-dev] [data-dev] New Tools and Challenges of Creating Modern TCK on Persistence Layer
|
Actually this means complexity, because
pre/post integration tests are not executed by an editor, so for
debugging or running individual tests or blocks of tests you have
to prepare the environment manually, run what you want (and be
careful to have all endpoints set correctly) and finally stop the
server.
BUT.
With some design I could use tests and
wrap them ie. to JUnit5 extension like I do that with GlassFish
integration tests here:
Or with more complex tests here:
These tests can be executed from editor
too, same as from Maven.
On 28. 04. 23 13:30, Manfred Riem
wrote:
What about just
- Maven
projects for the tests.
- Write them
as Junit 5 tests.
- Failsafe
plugin.
- Vendor hooks
in at pre-integration / post-integration step.
No complexity. Setup as a regular project.
Done!
I am hesitant to agree with this
direction.
I've heard many times that Arquillian
is old and not "modern" but it's more modern than the
Vehicle approach of the current platform TCK.
Additionally, Arquillian has already
solved many of the roadblocks in place when writing
tests that need to run on a Jakarta EE platform.
I've used TestContainers extensively
and here are the roadblocks that Arquillian has solved
that we'd have to solve if we decided to switch to
TestContainers:
-
TestContainers doesn't have a standard Interface for
application server containers.
-
We would have to create one, and every Jakarta EE
platform would need to implement it (similar to how
every platform server has an Arquillian
implementation).
-
We would have to create a library similar to
ShrinkWrap that would allow us to programmatically
create applications and deploy them to the test
container.
-
We would have to create a set of protocol libraries
that also get deployed to the test container so that
tests only have to be written once but can be tested
either using:
-
Core profile: using REST
-
Web profile: using Servlet
-
We would have to figure out a way to distinguish
between tests that need to run on the client system
vs. inside the container.
-
We would have to create a deployment library that can
be extended by those running the TCK to allow for
one-off customizations to the application before it is
deployed.
-
For example, the Concurrency TCK allows vendors to
add custom *-ejb-jar.xml files to artifacts
before they are deployed.
-
Finally, all of this would need to be worked both into
the Junit5 lifecycle and the TestContainer lifecycle.
I honestly think the work I've done
on the Jakarta Data TCK shows how simple using
Arquillian can be and I even had to figure out a way
to make that TCK run both in a Standalone mode and on
different Jakarta EE profiles (core / web).
I don't think it is feasible to
make the jump from Vehicles to TestContainers for
Jakarta EE 11.
I also worry that using
TestContainers will raise the complexity of running
the TCK for vendors as opposed to Arquillian.
_______________________________________________
jakartaee-tck-dev mailing list
jakartaee-tck-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-tck-dev
--
David Matejcek | OmniFish
david.matejcek@xxxxxxxxxxx