I have an easy answer: GO FOR
TestContainers!
It is really easy to write tests with
GF and TestContainers - I already had a presentation on GeeCon
conference last week where I presented several ways to run tests
with GF. I use GF (and Jetty) with TC for some 6 years. It is
much more capable than Arquillian. When I was in Payara, I even
created Arquillian for Payara + TC and used the bloody old JSR-88
for deployment, but later I removed it, because:
* When I need an integration test, I
should not "hack" into the container, but test the integration
from the outside (remote mode of Arq)
* Integration test should do nearly the same steps like user would
do on production
* When I need a unit test, it is better
to test directly in the module and use weld-test project extended
with whatever I need; it can be extended also with mock support,
test improbable situations, etc.
* There is also much more flexibility,
I can combine both ways, ie. in one project I had selenium tests
with faked database in TestContainers and using dbunit. Very fast
-> can show issues with _javascript_+JSF (ie. when user is
clicking too fast on slow network/browser/overloaded client or
server system).
We already have some TC based tests in
GF, but I don't push more, because they cannot run on Eclipse's
Jenkins.
Also - you don't need anything
complicated, just JUnit5 and if you want to start-deploy-stop just
once, create a class which will control the "global environment";
with TC it can mean even network between docker containers.
Btw this test can be executed even from
Eclipse.
@Testcontainers
public class TrivialIT {
@Container
private static final GenericContainer SERVER = new GenericContainer<>("omnifish/glassfish:7.0.3")
.withExposedPorts(8080).withLogConsumer(o -> System.out.print("GF: " + o.getUtf8String()));
@Test
void getRoot() throws Exception {
URL url = new URL("http://localhost:" + SERVER.getMappedPort(8080) + "/");
StringBuilder content = new StringBuilder();
HttpURLConnection connection = (HttpURLConnection) url.openConnection();
try {
connection.setRequestMethod("GET");
try (BufferedReader in = new BufferedReader(new InputStreamReader(connection.getInputStream()))) {
String inputLine;
while ((inputLine = in.readLine()) != null) {
content.append(inputLine);
}
}
} finally {
connection.disconnect();
}
assertThat(content.toString(), stringContainsInOrder("Eclipse GlassFish", "index.html", "production-quality"));
}
}
On 27. 04. 23 20:03, Scott Stark wrote:
This discussion needs to loop in the
jarkataee-tck-dev list as well since component TCKs should be
composable into the profile and platform TCKs as well.
Dear
Jakarta Spec Leads,
I hope
this email finds you well. I am writing to discuss the
challenges we are facing while creating modern TCK on
the persistence layer and to introduce some new tools
that could help us overcome these challenges.
Currently,
most Jakarta EE specs use the Arquillian framework as
the core of the TCK. However, we have found that it
can be challenging to work with, especially for newer
developers, and it does not work smoothly on modern
IDEs such as IntelliJ.
Furthermore, the getting started documentation for
Arquillian references Java EE 7, a ten-year-old
version, and aligns differently from the current
Jakarta EE version 10.
Therefore,
we believe the Arquillian framework only makes sense
for legacy projects. We must explore new options to
create a more developer-friendly TCK for modern
projects.
We are
considering using JUnit Jupiter with TestContainer as
an alternative to Arquillian. We believe this approach
could simplify the testing process and make it more
accessible to new developers. Additionally, we aim to
create an easy-to-integrate, contribute, and
extensible TCK that can be used for both Jakarta NoSQL
and Data specifications.
We would
appreciate your thoughts and suggestions on this
matter, especially regarding the new TCKs we are
developing. We want to ensure that our approach
remains neutral to both specifications. We are open to
exploring other frameworks that could inspire our
work, such as Weld-testing, TestContainer, and JUnit
5.
Thank
you for your time and consideration. We look forward
to hearing from you soon.
--
_______________________________________________
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