Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakartabatch-dev] Batch TCK discussion continued - Junit 5, Arquillian, etc.
Hi.

On Fri, May 28, 2021 at 8:20 PM Romain Manni-Bucau <rmannibucau@xxxxxxxxx> wrote:
+1 there is no real adopted alternative to arquillian so reaching portability and integration easiness with per test app (archive) it looks a good move

Yes. Wherever possible, I try to create the tests using Arquillian to all use @RunAsClient. That way Arquillian is only used to start/stop the target (if applicable) and deploy/undeploy the test archive. The test project is always a regular war (in case of web tests), so that war can be deployed standalone (without Arquillian) as well. That provides maximum portability should, for some reason, testing without Arquillian becomes necessary.

I do wonder if it would be good to standardize some parts of Arquillian. The API itself has been stable for almost a decade now and it has long ago stopped to be fast moving (it's mostly simply complete).

Kind regards,
Arjan




 
. Junit 5 or 4 is no more important technically IMO so let's use 5 if we can to encourage contrib to tck themselved.

Le ven. 28 mai 2021 à 17:37, Scott Kurz <skurz@xxxxxxxxxx> a écrit :

Hi again,

I'd like to continue our TCK discussion (from:  https://www.eclipse.org/lists/jakartabatch-dev/msg00053.html ) and note some work Ondro has done:

https://github.com/OndroMih/batch-tck/pull/3  (this is at the 1.0 level and pre-formatting changes so a bit of a non-trivial merge ahead to master)
https://ondro.inginea.eu/index.php/possible-ways-to-use-arquillian-in-jakarta-ee-tcks/

If I understand correctly, it seems Ondro is proposing is to rewrite our TCK to use JUnit 5 APIs.  

From there, we can use an Arquillian JUnit 5 extension to extend / plug-in to JUnit 5:
https://search.maven.org/classic/#search%7Cga%7C1%7Cg%3A%22org.jboss.arquillian.junit5%22

The Arquillian extension, in turn, can be used with various container adapters,  remote/managed/etc., if desired, and he has prototyped integration w/ Payara.

However, it'd also be possible to use a non-Arquillian JUnit 5 extension as well.   (Hopefully am I summarizing this correctly.)

So, what do we think?   Romain, Cheng, does this address your concerns of not wanting to tie into Arquillian too tightly ?

Knowing Arquillian adapters already exist, it seems like a big advantage to be able to leverage them for Payara, Open Liberty, etc.  

(I'll note too the discussion is going on at the platform level too, (re: Batch and the other standalone TCKs), e.g. here:  https://github.com/eclipse-ee4j/jakartaee-platform/issues/333)

Thanks,
------------------------------------------------------
Scott Kurz
WebSphere / Open Liberty Batch and Developer Experience
skurz@xxxxxxxxxx
--------------------------------------------------------

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

Back to the top