Re: [jakartaee-tck-dev] [jakartaee-spec-project-leads] New Tools and Cha

[David Matejcek <david.matejcek@xxxxxxxxxxx>]

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

There's just one issue: no support on Eclipse Jenkins. Issue I created is still waiting for some love ... https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/2379

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.

On Apr 27, 2023 at 11:57:55 AM, Otavio Santana <otaviopolianasantana@xxxxxxxxx> wrote:

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.

--

Thanks a lot,

Twitter | Linkedin | Youtube

_______________________________________________
jakartaee-spec-project-leads mailing list
jakartaee-spec-project-leads@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-spec-project-leads

_______________________________________________
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