[wildfly-dev] Re: WildFly JUnit Extension and Tooling

I've added support for manual mode tests https://github.com/jamezp/wildfly-testing-tools?tab=readme-ov-file#manual.... If things look okay, I'd like to move this to either the wildfly or wildfly-extras organization as I'd like to start using it in the wildfly-maven-plugin. If we don't think we want something like this, that is okay too. I can just copy some things over to the wildfly-maven-plugin. James R. Perkins Principal Software Engineer On Tue, Oct 28, 2025 at 7:27 AM James Perkins <jperkins(a)redhat.com&gt; wrote: > > > James R. Perkins > > Principal Software Engineer > > > On Tue, Oct 28, 2025 at 6:37 AM Brian Stansberry <bstansbe(a)redhat.com&gt; > wrote: > >> First, just a note: if this becomes the replacement for org.wildfly.core.testrunner.WildFlyRunner then >> it would be used in the main WildFly code base. WildFlyRunner is used in >> testsuite/manualmode. The server lifecycle in that testsuite is not meant >> to span the surefire execution and is therefore controlled by the tests >> themselves. So some tests used WildFlyRunner instead of Aquillian. >> > > This is good to know. I thought we had a rule of not using it in the > WildFly test suite, but that might be wishful thinking on my part :) I > currently don't support manual mode, but that should be possible to > implement. > > >> >> Second, re the other tools, with that you've kind of opened the topic of >> wildfly-core-testsuite-shared, which is a somewhat messy mix of common >> utilities useful in testing any any stack based on the WildFly Core kernel, >> and then stuff that's just meant to be shared between various testsuite >> modules in WildFly Core itself. The former part being heavily used in the >> main WildFly testsuite. At a very quick glance, the tools stuff in your >> repo looks like more of the former. So we should think about where we want >> that kind thing to live. >> > > Agreed. That makes sense to me. The intent of this tooling is as you > assumed, tooling to be used for testing with a WildFly Core based server. > I'd be happy to move more utilities over as well. I'm sure there are things > other projects may find helpful. > > >> >> One factor in that kind of thinking is a distinction between the >> wildfly-core-testsuite-shared stuff and probably what you have in mind for >> your repo is that we generally say that the wildfly-core-testsuite-shared >> stuff can only be used in wildfly/wildfly-core or wildfly/wildfly. So if we >> changed something and that broke someone using it some other way, we'd not >> fix that if it interfered with the main needs. I'd think that if we moved >> something out of wildfly-core-testsuite-shared and into wildfly-testing-tools >> we'd be saying it's more broadly usable and we'd maintain it that way. >> > > Agreed which is why it's something I've left more generic, e.g. > start/stop a server, deploy an application, execute CLI commands, etc. I > hadn't planned on doing some kind of ServerSetupTask, but I guess that > could make sense that we could add some kind of task to execute before > deployments and after an undeploy. Something like that might make sense > though as we might be able to share it with WildFly Arquillian which IIRC > we did try to create some kind of a bridge at one point. > > >> >> On Mon, Oct 27, 2025 at 10:47 PM James Perkins via wildfly-dev < >> wildfly-dev(a)lists.jboss.org&gt; wrote: >> >>> Hello All, >>> In some free time, I created a new project for WildFly i'm calling >>> wildfly-testing-tools [1]. Currently this includes a JUnit Extension for >>> managing a WildFly instance for tests. Please note this is NOT a >>> replacement for Arquillian. This is aimed for cases that are much more >>> simple than what Arquillian can handle. >>> >>> This could end up being used in WildFly Core as a replacement for the >>> JUnit 4 TestRunner we have. The idea for this project came from me wanting >>> to migrate the wildfly-maven-plugin to use JUnit 6. I needed a replacement >>> for a simple test runner that is similar to what we have in WildFly Core, >>> so I created this :) >>> >>> I also moved some things from WildFly Arquillian into this project. The >>> reason being these were useful testing tools, but really don't have >>> anything to do with Arquillian. These extensions can be used with or >>> without Arquillian. >>> >>> I'd like to propose we make this a WildFly project. I'd like others to >>> have a look and let me know if they would find it useful. I don't think >>> it's something we want to bring into WildFly testing itself, but I can see >>> it being useful for WildFly Core or projects where Arquillian might be a >>> bit of an overkill. >>> >>> [1]: https://github.com/jamezp/wildfly-testing-tools >>> >>> >>> James R. Perkins >>> >>> Principal Software Engineer >>> _______________________________________________ >>> wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org >>> To unsubscribe send an email to wildfly-dev-leave(a)lists.jboss.org >>> Privacy Statement: https://www.redhat.com/en/about/privacy-policy >>> List Archives: >>> https://lists.jboss.org/archives/list/wildfly-dev@lists.jboss.org/message... >>> >> >> >> -- >> Brian Stansberry >> Architect, JBoss EAP >> WildFly Project Lead >> He/Him/His >> >