Mocking is gay and the worst idea I ever heard of. You end up just
testing mock implementations.
AOP and commons are an API issue, not an SPI one. You're not gonna be
able to mock AOP or commons even if you thought that was a good idea.
For JGroups, do what EJB does. EJB has a cache interface/SPI contract
with the EJB container itself. A cache plugin SPI. Where EJB(2/3) went
wrong is that JBoss Cache implementations of the SPI should have been
pulled out into their own build structure so that they could easily be
branched.
Tim Fox wrote:
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.
>
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
--
Bill Burke
JBoss, a division of Red Hat
http://burkecentral.blogspot.com