I've migrated the Arquillian Spock Extension to use a
SessionLauncherListener (see the latest commits at
https://github.com/topicusonderwijs/arquillian-testrunner-spock/tree/spock-2.0-junit5
). This now works perfectly with the updated maven-surefire-plugin.
Arquillian is now only started once per
Hi Marc,
With forkCount = 1 it works fine, the problem is with forkCount > 1. The
Arquillian extension registers its state in the store at the root of the
TestPlan. When running with forkCount > 1, surefire sets up a load balancer
in the main process. This load balancer streams tests one by one
Hi Emond,
could you please elaborate why the LauncherSessionListener approach doesn’t
work for forkCount=1 for Arquillian?
Cheers,
Marc
> On Sunday, Sep 12, 2021 at 9:37 PM, Emond Papegaaij
> mailto:emond.papega...@gmail.com)> wrote:
> Hi Marc,
>
> Thanks for the links to the documentation.
Hi Marc,
Thanks for the links to the documentation. This really helps for my
Arquillian-Spock extension. It's good to know the LauncherSession was
introduced to solve this issue.
The problem I see with this new API is that it requires the extension to
explicitly make use of it. For example, the
Hi Tibor,
I've reworked the commit to keep the JUnit version at 1.3 and use
reflection to get the session. Also, I've fixed the issue with the session
used for scanning tests in main thread that remained open. The formatting
is now in line with the checkstyle rules and all tests pass.
LauncherSessionListener can be obviously used as a hack by the end users
but I do not see the reason why we should use it.
We do not want to explicitly call fixture methods because this would lead
to maintenance if Junit5 introduces new fixture mechanisms.
On Sat, Sep 11, 2021 at 12:25 PM Tibor
I do not want to stick to the latest version 1.8.
We have to stick to version 1.3 as it is right now.
We do not have a critical issue which could not be solved by reflection.
This reflection call, I proposed in GH, is made only once, no performance
penalty.
T
On Sat, Sep 11, 2021 at 7:52 AM Marc
Hi Emond and Tibor,
I’m glad you discovered the new LauncherSession API which was added for this
purpose. The JUnit 5.8 GA release will come in the next few days.
As you mentrioned, the official documentation does not (yet!) do a good job of
explaining its intended use case:
Hi Emond,
This section of code is executed for the forkCount > 1
https://github.com/apache/maven-surefire/blob/master/surefire-providers/surefire-junit-platform/src/main/java/org/apache/maven/surefire/junitplatform/JUnitPlatformProvider.java#L194-L202
The above part runs if the forkCount is 1.
Hi Tibor,
That's what I implemented, although I couldn't use the fancy try, because
of the way the code is structured. The LauncherSession is started by
LazyLauncher. This will allow registering a listener for opening and
closing the session, given a place for pre and post fixtures.
Best
Hi Emond,
Are you looking for this?
https://github.com/junit-team/junit5/blob/main/documentation/src/test/java/example/UsingTheLauncherDemo.java#L86-L96
On Fri, Sep 10, 2021 at 10:49 PM Emond Papegaaij
wrote:
> On Fri, Sep 10, 2021 at 9:15 PM Emond Papegaaij >
> wrote:
>
> > On Fri, Sep 10,
On Fri, Sep 10, 2021 at 9:15 PM Emond Papegaaij
wrote:
> On Fri, Sep 10, 2021 at 8:41 PM Christian Stein
> wrote:
>
>> On Fri, Sep 10, 2021 at 8:27 PM Emond Papegaaij <
>> emond.papega...@gmail.com>
>> wrote:
>>
>> For now, I think the LauncherSession is the best way to at least provide
>> >
On Fri, Sep 10, 2021 at 8:41 PM Christian Stein wrote:
> On Fri, Sep 10, 2021 at 8:27 PM Emond Papegaaij >
> wrote:
>
> For now, I think the LauncherSession is the best way to at least provide
> > some hooks for pre and post fixtures. It shouldn't be too hard to get
> this
> > in the current
Sorry for typos, I sent it from my mobile.
T
On Fri, Sep 10, 2021 at 6:18 PM Tibor Digana wrote:
> We have to dig into Junit 5. Surefire is a streamer of classes across the
> forks which is our load balancer. Therefore each class is running
> separately, pre and post fixtures. If the Junit 5
On Fri, Sep 10, 2021 at 8:27 PM Emond Papegaaij
wrote:
> [...]
For now, I think the LauncherSession is the best way to at least provide
> some hooks for pre and post fixtures. It shouldn't be too hard to get this
> in the current code base with backwards compatibility for JUnit Platform
> 1.7
On Fri, Sep 10, 2021 at 6:18 PM Tibor Digana wrote:
> We have to dig into Junit 5. Surefire is a streamer of classes across the
> forks which is our load balancer. Therefore each class is running
> separately, pre and post fixtures. If the Junit 5 used Java Streamer
> including dome kind of
We have to dig into Junit 5. Surefire is a streamer of classes across the
forks which is our load balancer. Therefore each class is running
separately, pre and post fixtures. If the Junit 5 used Java Streamer
including dome kind of control of fixtures then web would have this issue.
Dňa pi 10. 9.
On Fri, Sep 10, 2021 at 5:06 PM Tibor Digana wrote:
> If you use forkCount > 1, the Surefire loads test classes via load
> balancer.
> If you use default forkCount = 0, all the classes are run eagerly as a
> suite via JUnit5 Launcher in one shot.
>
Yes, this is what I saw in the
Please read the documentation
https://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html
On Fri, Sep 10, 2021 at 5:05 PM Tibor Digana wrote:
> If you use forkCount > 1, the Surefire loads test classes via load
> balancer.
> If you use default forkCount = 0, all the classes
If you use forkCount > 1, the Surefire loads test classes via load balancer.
If you use default forkCount = 0, all the classes are run eagerly as a
suite via JUnit5 Launcher in one shot.
If you are aiming for Arquillian, testing the applications in the
application server, you should use
Hi all,
First of all, sorry for the lengthy post. I decided to add some context to
explain things a bit, but it resulted in quite a long e-mail. For the past
few weeks I've been trying to come up with a solution for the issue I
filled under SUREFIRE-1935, but I'm getting stuck and starting to
21 matches
Mail list logo