| Re: [jakartaee-tck-dev] [jakartaee-spec-project-leads] New Tools and Challenges of Creating Modern TCK on Persistence Layer |
On 27. 04. 23 22:03, Scott Stark wrote:
Do you have a git repo for an example integration?All repos except PAYARA-4176 were private. But P4176 is an overkill for the TCK.
For the TCK I would do something lighter.
- yeah, the environment was also injectable to tests (using @Inject), so I could ie. delete the JDBC pool in between and watch consequences. Not much useful for the TCK, probably.
As I wrote, if Arquillian is capable of connecting to a remote host:port or better some configured remote endpoints, it can be used too, ok. Btw, will it move to Eclipse if it is so useful again? It needs a maintenance.
Btw now we run TCK tests locally for GlassFish this way:
- it uses TestContainers for the mail server -> no go on Jenkins, we tried: https://ci.eclipse.org/glassfish/job/glassfish7-all-tests/ (Jenkins removes failed builds, there was more)
_______________________________________________
This is an unpublished code I used temporarily to test GlassFish start/stop (perhaps you remember those issues on Jenkins TCK), i pushed it just for this email, this is not a prod-quality:
Years ago we had some 70000 tests with TC using Jetty, several databases, JMH, Newman/Postman, quite large thing. Before that I used GF and Payara with Arquillian. Always some issues with that, things it doesn't know, rigid XML, ... that's why I am worried about Arquillian. But it always has pros and cons.
Basically - you can still use Arquillian. And I can remember how I combined it with the TestContainers, so we can have safely both together, and later consider other solutions. It would be still easier than migration from the Ant hell.
But I still need the TC support on Jenkins. Without that - no TC.
I have found the integration in history of my repo, but I think I removed it after I was disappointed with the HTTPS (not trusted cert) or something like that, while directly using asadmin was easier:
public class PayaraDockerDeployableContainer implements DeployableContainer<PayaraDockerContainerConfiguration> {
...
@Override
public ProtocolMetaData deploy(final Archive<?> archive) throws DeploymentException {
LOG.debug("deploy(archive={})", archive);
Objects.requireNonNull(archive, "archive must not be null");
// TestContainers
final PayaraServerContainer payara = environment.getPayaraContainer();
final String applicationName = payara.deploy(APP_CONTEXT_ROOT, archive);
logDeployedApplicationStatus(payara, applicationName);
final URL httpUrl = payara.getHttpUrl();
final HTTPContext httpContext = new HTTPContext(httpUrl.getHost(), httpUrl.getPort());
httpContext.add(new Servlet(applicationName, APP_CONTEXT_ROOT));
final ProtocolMetaData protocolMetaData = new ProtocolMetaData();
protocolMetaData.addContext(httpContext);
return protocolMetaData;
}
On Apr 27, 2023 at 12:44:43 PM, David Matejcek <david.matejcek@xxxxxxxxxxx> wrote:
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/2379We 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.
--
_______________________________________________
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_______________________________________________
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
jakartaee-tck-dev mailing list
jakartaee-tck-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-tck-dev