Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakartaee-tck-dev] Example appclient vehicle ported tests
To follow up on what we discussed yesterday regarding "The arquillian container needs to bring the test results back to junit.", I'm going to work on ensuring that the appclient container can correctly marshall test failures which I think is currently not working well enough yet (as least not the same as the Java Test harness handled failures).

To test ^, I'm going to update the com.sun.ts.tests.ejb30.common.appexception.ClientBaseAtOnlyTests#atCheckedAppExceptionTest to log a message and throw a failure like this:

"
public void atCheckedAppExceptionTest() throws TestFailedException {
//try {
 TLogger.log("atCheckedAppExceptionTest will force the test to fail by throwing new TestFailedException" );
throw new TestFailedException(
"simulate test failure by throwing TestFailedException exception");
// bean.atCheckedAppException();
 //throw new TestFailedException(
 // "Did not get expected exception: AtCheckedAppException");
 //} catch (AtCheckedAppException e) {
 // TLogger.log("Got expected exception: " + e);
 //}
}
"

I think that I saw some problems with marshalling test failures before when we were running the wrong tests before.  I think we are correctly collecting all of the launched appclient container output as an array of strings but I think we need more changes to what we do with the console output in the case of failure.  

Scott

On Tue, Feb 6, 2024 at 3:00 PM Scott Marlow <smarlow@xxxxxxxxxx> wrote:


On Tue, Feb 6, 2024 at 2:51 PM Scott Marlow <smarlow@xxxxxxxxxx> wrote:




On Tue, Jan 23, 2024 at 11:55 AM Scott Stark via jakartaee-tck-dev <jakartaee-tck-dev@xxxxxxxxxxx> wrote:
As I mentioned on the last tck-dev call, I have ported 3 examples of a
legacy JavaTest appclient test over to Junit5/Arquillian. The example
repo for running these tests against WildFly is here:
https://github.com/jakartaredhat/wildfly-eetck.git

As stated in the
https://github.com/jakartaredhat/wildfly-eetck/blob/main/README.md,
there are 2 snapshot builds of dependent repos needed to successfully
run:

* The WildFly Arquillian container:
git clone https://github.com/starksm64/wildfly-arquillian.git

This includes an updated Arquillian managed container that supports
both the launching of the appclient test artifact to the server as
well as the launching of the appclient container to run the appclient
main method entrypoint. This requires a new appclient protocol that
does the actual launch of the appclient main process and parses the
output to produce the test result. The appclient protocol should be
pulled out into a common protocol at some point as it should be a
common protocol that has no ties to WildFly container specific
behavior.

* The Jakarta EE TCK Arquillian/Junit5 tests:
git clone https://github.com/jakartaredhat/jakartaee-tck.git
branch is ejb-arq-test

This is a branch of the tckrefactor branch that has the following tests ported:
com/sun/ts/tests/ejb30/bb/session/stateless/basic/ClientTest.class
com/sun/ts/tests/ejb30/bb/session/stateless/annotation/appexception/annotated/ClientTest.class
com/sun/ts/tests/ejb30/bb/session/stateless/annotation/enventry/ClientTest.class

Scott Marlow had sent an email about some issues with the appexception
ClientTest and then updated its base class behavior to match what we
saw in the run of the legacy JavaTest runs. These tests are still
using logic from the JavaTest days because the mechanism for asserting
if a test passes is coupled to a consistent format for the log output
of the test.

Next steps are to add an ejblite vehicle and then to pull in how the
vendor porting libs and configuration properties usage need to be
supported. Hopefully with those two updates there will be a better
idea of what automation could be done.

Pulling the appclient protocol and framework into the
arquillian-jakarta repo for use by other vendor container
implementations is also next step.

Take a look and this and provide comments if you can. We will talk
about it in the next dev meeting.


For other next steps perhaps we can update the platform-tck-tools Jar2ShrinkWrap.java to use the mapping at VehicleRunnerFactory.java#L337 to determine which vehicles should be used for each TCK test.  

The Standalone TCKs in the Platform TCK have vehicles (not listing the Platform/profile test vehicles here):

- annotations/caj no vehicles as currently there are no tests other than signature testing.
- connector {connectorservlet} vehicle.
- expressionLanguage/el {standalone} vehicle.
- authorization/jacc {standalone, ejblitesecuredjsp} vehicles.
- jaxws {standalone} vehicle.
 
- jms {standalone} vehicle.
- jpa {standalone} vehicle.
- jsp no vehicles.properties file which I think means the same as {standalone} vehicle.
- jstl no vehicles.properties file which I think means the same as {standalone} vehicle.
- jta { servlet, jsp, standalone} vehicles.
- soapAttachments/saaj {standalone }.
- websocket {standalone }

Sorry, I had pressed send too soon in my previous email.

Scott



Thanks,
Scott
_______________________________________________
jakartaee-tck-dev mailing list
jakartaee-tck-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-tck-dev

Back to the top