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

On Thu, Nov 13, 2025 at 2:02 PM James Perkins <jperkins(a)redhat.com&gt; wrote: > > > James R. Perkins > > Principal Software Engineer > > > On Thu, Nov 13, 2025 at 9:36 AM Brian Stansberry <bstansbe(a)redhat.com&gt; > wrote: > >> Moving to wildfly-extras sounds ok. This seems like quite a lot and >> it's pretty new so the incubating nature gives a bit more freedom to break >> things you decide aren't right. >> > > That makes sense to me. > > >> >> If this is going to surface in the feature set of wildfly-maven-plugin >> then you're already in a mode of "can't break that", so going straight to >> the 'widlfly' org would make more sense. But I think maybe you mean you are >> going to use this as part of the infrastructure to test >> wildfly-maven-plugin? That's an internal detail and using incubating stuff >> is fine. >> > > Nothing will be exposed from the wildfly-maven-plugin, I just want to use > it for testing so I can start migrating tests to use JUnit 6. > > >> >> Tangent: the minVersion thing for a module seems a bit underspecified, >> as modules don't have versions. The server that uses the module does, which >> is what I think you mean. (Note my understanding of this is 100% from the >> README; I didn't look at the code.) >> > > I do need to do some work on the README now that it has grown. The idea > behind that is you can enable/disable a test based on the version defined > in an artifact/resource provisioned in the server. I can see where it can > be a bit confusing, but the idea is you write a test that only works on > newer versions of WildFly, but you want to also test with older versions. > Instead of having to specify a bunch of profiles to tags for each version, > you can simply use the minVersion to say "This test only works on WildFly > 38 and higher, please ignore it on lower versions". Given modules > themselves don't have versions, I suppose that can be confusing. However, > I've found it very useful in RESTEasy to resolve the version from the > artifact GAV or downloaded JAR. > Yeah, it makes sense; it's really just a matter of wording. And likely people will get the idea regardless. \

> >> >> On Mon, Nov 10, 2025 at 2:21 PM James Perkins <jperkins(a)redhat.com&gt; >> wrote: >> >>> 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 >>>>> >>>> >> >> -- >> Brian Stansberry >> Architect, JBoss EAP >> WildFly Project Lead >> He/Him/His >> > -- Brian Stansberry Architect, JBoss EAP WildFly Project Lead He/Him/His