[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
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.
https://github.com/payara/Payara/blob/17a70c90b1fe3f3c551b49380e977909edb6b271/appserver/tests/test-containers/cloud/src/test/java/fish/payara/test/containers/tst/jdbc/JdbcPoolITest.java
https://github.com/payara/Payara/blob/17a70c90b1fe3f3c551b49380e977909edb6b271/appserver/tests/test-containers/cloud/src/test/java/fish/payara/test/containers/tst/jta/timeout/JtaTimeoutLoggingITest.java
https://github.com/payara/Payara/blob/17a70c90b1fe3f3c551b49380e977909edb6b271/appserver/tests/test-containers/tools/src/main/java/fish/payara/test/containers/tools/env/DockerEnvironment.java
- 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:
https://github.com/eclipse-ee4j/glassfish/blob/master/appserver/tests/tck/tck-runner/src/test/java/org/glassfish/main/tests/tck/ant/tests/EjbITest.java
https://github.com/eclipse-ee4j/glassfish/blob/master/appserver/tests/tck/tck-runner/src/main/java/org/glassfish/main/tests/tck/ant/TckRunner.java
- 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:
https://github.com/dmatej/glassfish/blob/03f70d14f9ca2e1fe4be9322cd2643c9cc610824/appserver/tests/testcontainers/src/test/java/org/glassfish/main/test/tc/DomainRestartITest.java
https://github.com/dmatej/glassfish/blob/03f70d14f9ca2e1fe4be9322cd2643c9cc610824/appserver/tests/testcontainers/src/test/java/org/glassfish/main/test/tc/GlassFishContainer.java
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;
}
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
--
David Matejcek | OmniFish
david.matejcek@xxxxxxxxxxx