Thanks everyone for the context. I agree with Matt, we should plan to move some quick wins to the modules they belong too and avoid growing the activemq-unit-tests when it's not necessary. And I also agree that we need to wait on this task until we finish the build stabilization and the Java 25 work.
I'll try to keep that in mind. So far on my todo list, I have already the JUnit upgrade to 6.x as discussed end of last year. So I can address some part of it when it's also done. -- Jean-Louis Monteiro http://twitter.com/jlouismonteiro http://www.tomitribe.com On Tue, Jan 20, 2026 at 12:57 AM Christopher Shannon < [email protected]> wrote: > Yeah, I think there's probably a lot of historical context here. Tests have > been consistently added to the testing module for as long as I have been > around. Also as Matt said it makes testing things that go across modules > easier, you can also share utilities etc. We can definitely re-organize > things better if it makes sense though. > > On Mon, Jan 19, 2026 at 3:24 PM Matt Pavlovich <[email protected]> > wrote: > > > Also, there is a lot of historical / technical debt in the > > activemq-unit-tests module. > > > > Some folks here like a one-big-unit-tests for validating changes and > > releases. > > > > I think the one-big-module muddies things and especially makes things > like > > modularity (ensuring class path separation, and correct limiting of > > transitive dependencies becomes impossible with one-big-module. > > > > As JB said, the problem with putting ‘broker’ tests in activemq-broker is > > it creates circular dependencies. Testing the activemq-http could mostly > > occur in activemq-http (but not activmeq-broker)— however, if you want to > > cross-cut things like http+persistence > store+interop-across-other-protocols > > you end up needing to put the test in activemq-unit-tests. > > > > I think there are some big swath things that could move to separate > > modules— activemq-jdbc tests by DB provider, for example. The > > cross-protocol testing, etc. > > > > I think re-orging the unit tests is a good goal, but I think we should > try > > to push it out later in favor of other priorities — current test fixes, > > Jetty 12, new website, etc. > > > > My $0.02 > > > > Matt > > > > > On Jan 19, 2026, at 7:19 AM, Jean-Louis Monteiro < > > [email protected]> wrote: > > > > > > Yes, that was my point and I agree that what can be in the module > should > > > stay there. > > > We do a lot of integration tests bootstrapping the broker and even if 1 > > > test is quick, it overall takes time and some of them could really be > > unit > > > tests. > > > > > > Thanks for the clarification, it helps > > > -- > > > Jean-Louis Monteiro > > > http://twitter.com/jlouismonteiro > > > http://www.tomitribe.com > > > > > > > > > On Mon, Jan 19, 2026 at 2:12 PM Jean-Baptiste Onofré <[email protected]> > > > wrote: > > > > > >> Hi > > >> > > >> Historically, we have the activemq-unit-test module to host tests > > >> applicable across multiple parts of the project or to test specific > > Jira. > > >> We also have tests inside each module related to the module itself. > > >> > > >> The "challenge" is about the broker because the broker module gathers > > all > > >> other modules. > > >> > > >> So, I would say that any module which is not broker (activemq-amqp, > > >> activemq-http, activemq-jaas, ...) should have their own test. > > >> The broker and client tests are either in the module or in the > > >> activemq-unit-test module (depending on the scope). > > >> > > >> To better understand the cause of the test failure, I think it would > > not be > > >> bad to have the activemq-unit-test tests dispatched in modules > > >> (broker/client) where it makes sense, and really keep only cross > module > > >> test in activemq-unit-test. > > >> > > >> Regards > > >> JB > > >> > > >> On Mon, Jan 19, 2026 at 11:56 AM Jean-Louis Monteiro < > > >> [email protected]> wrote: > > >> > > >>> Hi all, > > >>> > > >>> I have a question regarding testing in ActiveMQ. > > >>> > > >>> I’m noticing that many tests under activemq-unit-tests are very > scoped > > >> to a > > >>> single module, and (at least at first glance) could live alongside > the > > >> code > > >>> they test. On recent PRs, this pattern seems to continue. > > >>> > > >>> Is there a rule or guideline that unit tests should be placed under > > >>> activemq-unit-tests/ rather than in the module they belong to? > > >>> > > >>> Having a dedicated module makes sense to me for integration-style > tests > > >> (or > > >>> anything that needs a wider broker setup / multiple modules). But for > > >> tests > > >>> that only exercise code within a given module, I’m curious what the > > >>> rationale is (history, dependency constraints, shared test utilities, > > >>> etc.). > > >>> > > >>> It’s not a problem per se, but activemq-unit-tests has grown quite > > large > > >>> and is difficult to run locally. Splitting truly module-local tests > > back > > >>> into their owning modules could make local iteration easier. > > >>> > > >>> Thanks in advance for any context! > > >>> -- > > >>> Jean-Louis Monteiro > > >>> http://twitter.com/jlouismonteiro > > >>> http://www.tomitribe.com > > >>> > > >> > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > For further information, visit: https://activemq.apache.org/contact > > > > > > >
