Ok, the 'integrationtests' module, is for Java client against *any* broker or *any* client in *any* language. The name may be a bit misleading, but that is what that module is for. That is why the interop tests are there, and if they are run in-vm, then they don't interop anything. You could run them in-vm, but it would be pointless.
'systests' is for Java client + Java broker only. The java messaging system in isolation from any other implementation. Unit tests under 'client' are for unit testing the client code only. In fact, they do not fit that intention and instead most of them are more like the tests under 'systests'. More correctly, they could be moved there. So far, no-one can be bothered to do that, as it hasn't been a problem. Rupert On 27/09/2007, Arnaud Simon <[EMAIL PROTECTED]> wrote: > > On Thu, 2007-09-27 at 10:20 +0100, Rupert Smith wrote: > > Integration tests and client unit tests are quite dissimilar. > > > > The integration tests are aimed at interop. The client unit tests are > > supposed to be pure unit tests for the client, but in fact they are > > more like Java client + broker sys tests. > > This is the issue, the client unit tests are not pure unit tests for the > client but more client+broker tests. Some of them are even more broker > oriented. Those tests should therefore be run as part of testing the > integration between a java client and a broker. That is to say that when > those tests are run against a in-VM broker then they can be viewed as > "unit" tests and when a remote broker is used as "integration" tests. > Providing a configurable way of choosing the type of broker used to run > those tests would provide us with both options. > > > Integration tests should not be run against an in-vm broker. > > Why not? > > > > > > >
