Convert tests to JUnit 5

[OndroMih]

Converts all TCK tests from TestNG to Junit 5. It also modifies the example TCK runner for JBatch to use work with the converted tests.

This PR also removes several public static void setup( methods in some tests which seemed to be not used at all.

Here's an example how to run the converted TCK on Payara Server using an unofficial JUnit 5 Arquillian extension: https://github.com/OndroMih/Payara-Batch-TCK-Runner/tree/poc-junit5-over-arquillian

More details on my blog: https://ondro.inginea.eu/index.php/possible-ways-to-use-arquillian-in-jakarta-ee-tcks/

[scottkurz]

Hi @OndroMih .. I had a chance to look this over more and I think I understand better. Thanks so much for writing up all the notes along the way including your blog post. (Sorry it took so long to get a response.)

So let me try to echo it back to you to confirm I understand, and then we can open up the topic again back on the mailing list.

So your two PRs here are parallel options. The one doesn't really build upon the other directly (maybe only as a learning exercise as you described in your blog).

Arquillian

In the other PR, #4, we stay with TestNG but refactor the tests to org.jboss.arquillian.testng.Arquillian. You showed how to run this in the com.ibm.jbatch.tck.exec module with a local Arq container, and you also could use the deployment approach from https://github.com/OndroMih/Payara-Batch-TCK-Runner to run with a managed or remote container, like the one for Payara.

This approach though would lead us back to Romain's objections concerning Arquillian which he brought up on the ML.

JUnit 5

In the current PR, #3 we refactor the tests from TestNG to JUnit 5 APIs. We then use an Arquillian JUnit 5 extension to plug into JUnit. In bringing Arquillian into JUnit we also gain the pluggable containers Arquillian supports, allowing someone to use a similar approach as your Payara-Batch-TCK-Runner if desired. (So it's a Payara adapter for the Arquillian extension of Junit 5, you might say).

With this approach, one would think, even someone who hates Arquillian or think it's outdated should be happy because.. they can write their own JUnit 5 extension, since the TCK is written to the JUnit 5 API.

Summary

So you're proposing #3 could satisfy both people who did vs didn't want to use Arquillian (whereas #4 wouldn't get merged).

Did I basically get that right? If so, let's go back to the mailing list for the next step of discussion.

I just didn't want to waste time by starting off with you setting me straight if I wasn't understanding.

Thanks again for moving this discussion along and writing this up so helpfully.

[scottkurz]

Interesting, I see there's some discussion here: jakartaee/platform#333 as well about your approach Ondro

[OndroMih]

Hi @scottkurz, yes, you got me right. The 2 proposals are alternatives, they shouldn't be used together, only one of them.

The solution with Arquillian + TestNG relies on Arquillian, because TestNG isn't flexible enough to allow people to choose whether they use Arquillian or not. Those who don't need Arquillian need to use Arquillian SE container which runs the tests in plain JVM. This solution is currently used by CDI and BVal.

The solution with JUnit 5 allows to choose the extension via configuration. So it's possible to choose Arquillian or any other solution, or even run the tests without an extension in the current JVM. However, this may only be true for Batch TCK which doesn't need different deployments and can run all tests with the same classpath. Some other TCKs would still want to rely on Arquillian even with JUnit 5 to define test packages to isolate tested classes, so they would just use JUnit 5 + Arquillian instead of TestNG + Arquilllian. But that's not relevant if we just want to discuss a solution for Batch. With Batch, I simply created an Arquillian extension that builds a deployment package that includes everything.