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
