Because, it makes absolutely certain that the version independent tests we are running, are the same across all versionw, irrespective of branch. Arnaud has helpfully converted some of these tests on trunk to use JMS (perftests), but these changes have not made it onto the other branches. We have changed the tests on M2/2.1 to get them passing, but are having a hard time merging those valuable fixes down onto trunk.
It makes sense, from the point of view of doing regression testing. This goes back to the debate about rewriting from scratch versus improving the Java client to get it to 0-10. As we went for the complete rewrite option, we can only measure whether or not we have carried forward behaviour correctly from the old to the new with tests. The tests are already beginning to diverge, and thereby losing some of their value. Rupert On 27/09/2007, Robert Godfrey <[EMAIL PROTECTED]> wrote: > > On 27/09/2007, Rupert Smith <[EMAIL PROTECTED]> wrote: > > > > On 27/09/2007, Rajith Attapattu <[EMAIL PROTECTED]> wrote: > > > > > > We should agree on strategy and the timing on executing it. I also > agree > > > that we need to involve everybody not just java folks. > > > > > > > Actually, it is the Java that has these problems, because the other > > languages are generally being worked on, on only one branch, or only by > > one > > group of people. It is the Java where the divergence between > > groups/branches > > is becoming a burden. Also, due to JMS, we can more easily write version > > independent tests. Therefore, I think we can move Java tests without > > consent > > of non-java folks, so long as they are in general happy with the > location > > they are being moved to. > > > > > OK - I'm really not sure what a /qpidtests buys us. > > I completely understand the idea of separating JUnit style unit tests from > the tests which require a whole broker+client to be running. > > I completely agree with re-writing the tests which use InVM so that they > can > be run against a broker running outside the VM (e.g. the C++ broker). > > But why are we proposing moving tests out of /qpid and into /qpidtests. > Sorry if I am being think... but what does this give us other than a more > disjoint structure? > > And on Carl's excellent points, I would expand > > > 1.) to be able to run all the applicable tests from Java against both > > brokers > > to be > > 1) To run *all* client tests (whatever language) against *any* broker > (Java, > C++, Rabbit, OpenAMQ or Other) > > There is nothing special about the Java client here... > > -- Rob >
