So what you're saying is that a lot (maybe most) of the tests in our
test suite are actually integration tests and should go into AS. (The
current messaging integration tests in are really crappy)
And the JBM test suite should only deal with mocks. So we need to mock
out usage of JGroups, AOP, the database, commons core etc
This is a nice idea, but it is a _lot_ (read huge) amount of work. It
would certainly speed our test suite up though.
We should remember JBM has been a standalone product until very recently
so has had to handle all its own testing (i.e. can't relay on AS
integration tests) that's why everything is in its own test suite.
Adrian wrote:
On Thu, 2007-07-19 at 16:08 +0100, Tim Fox wrote:
> The issue is really just that we test against version X of aop, version
> Y of jgroups, version Z of core libs since that is what AS 4.2 uses, so
> our tests are only valid with those versions.
>
You're talking about integration testing.
That's not your problem, that's a problem for the AS
integration testsuite.
It's only your problem if your doing the integration of
JBoss Messaging version X into JBossAS version Y.
You run the integration tests and if they don't pass,
you don't commit.
What is your problem is those integration tests fail
because JGroups version A doesn't work
like JGroups version B because you used something that
either wasn't meant to be used that way or that wasn't
regression tested for the way you use it.
It's only by solving the second problem
(clean and tested integration between individual projects)
that the first problem
(JBossAS can pick and choose which versions of projects
it wants to integrate) doesn't become an N^2 problem.
You've still got to run two integration tests,
jboss-4.2.x and jboss-5.x, regardless.