ActiveMQ testing rules?

[Jean-Louis Monteiro <jl...@tomitribe.com>]

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

Re: ActiveMQ testing rules?

[Jean-Louis Monteiro <jl...@tomitribe.com>]

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 <
christopher.l.shannon@gmail.com> 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 <ma...@apache.org>
> 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 <
> > jlmonteiro@tomitribe.com> 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é <jb...@nanthrax.net>
> > > 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 <
> > >> jlmonteiro@tomitribe.com> 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: dev-unsubscribe@activemq.apache.org
> > For additional commands, e-mail: dev-help@activemq.apache.org
> > For further information, visit: https://activemq.apache.org/contact
> >
> >
> >
>

Re: ActiveMQ testing rules?

[Christopher Shannon <ch...@gmail.com>]

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 <ma...@apache.org> 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 <
> jlmonteiro@tomitribe.com> 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é <jb...@nanthrax.net>
> > 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 <
> >> jlmonteiro@tomitribe.com> 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: dev-unsubscribe@activemq.apache.org
> For additional commands, e-mail: dev-help@activemq.apache.org
> For further information, visit: https://activemq.apache.org/contact
>
>
>

Re: ActiveMQ testing rules?

[Matt Pavlovich <ma...@apache.org>]

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 <jl...@tomitribe.com> 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é <jb...@nanthrax.net>
> 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 <
>> jlmonteiro@tomitribe.com> 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: dev-unsubscribe@activemq.apache.org
For additional commands, e-mail: dev-help@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact

Re: ActiveMQ testing rules?

[Jean-Louis Monteiro <jl...@tomitribe.com>]

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é <jb...@nanthrax.net>
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 <
> jlmonteiro@tomitribe.com> 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
> >
>

Re: ActiveMQ testing rules?

[Jean-Baptiste Onofré <jb...@nanthrax.net>]

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 <
jlmonteiro@tomitribe.com> 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
>