Unit tests

• All inputs and outputs to the component should be tested.

• During the test, the component should not use any third party components - e.g. database, jgroups or MINA directly. It should work only with mock or fake implementations of other components. Working with mocks or fakes allows the tests to run extremely quickly, which is crucial for quick refactoring, and a test-driven development approach. No component is allowed to be committed without full unit tests involving mocks or fakes where appropriate. Any dependencies with third party components, should be abstracted out to a very thin integration layer. Our core components should only deal with the abstracted out interfaces, never with the real component interfaces, this allows to us to create mock/fake implementations easily.

• Any Thread.sleep(...) calls are banned in unit tests. Again this is crucial to ensure speedy execution of tests. If you need to wait for an action to occur asynchronously you should use a latch or Object.wait/notify or better still refactor the component to be able to test the same code without having to wait for an asynchronous action.

• Timing sensitive tests. Some times it is not possible to avoid unit tests that need to sleep for a condition. E.g. a scheduled delivery test where i send a message for delivery in 5 seconds time - in this case the test would need to sleep for 5 seconds. There should only be a very small number of tests that do this. These tests should exist in a separate directory for timing sensitive tests.

Concurrency tests

These are similar to unit tests, in that they test a particular component with no third party dependencies. But they test the component with many threads concurrently. These kinds of tests may take longer to run than normal unit tests, so should exist in a separate directory for concurrent tests.

Integration tests

We will provide a smaller number of tests which test the system with the real third party components, e.g. real BDB, real MINA. We do not need so many tests in the integration test suite. What is more important is wide coverage but not to so much depth as unit tests.

Most of the current JMS tests are in fact unit tests.

Compliance tests

TCK - this is run by QA

JORAM

Stress tests

Soak tests

Tests package layout

We will adopt the following package layout scheme in JBM 2.0:

Unit tests, concurrent tests and timing tests will exist in the same package hierarchy as the code.

E.g.

• org.jboss.messaging.core.impl.test.unit - contains unit tests for classes in org.jboss.messaging.core.impl

• org.jboss.messaging.core.impl.bdbje.test.unit - contains unit tests for classes in org.jboss.messaging.core.impl.bdbje

• org.jboss.messaging.core.impl.test.unit.fakes - contains fakes for any classes in org.jboss.messaging.core.impl

• org.jboss.messaging.core.impl.test.timing - contains any timing sensitive tests for any classes in org.jboss.messaging.core.impl

• org.jboss.messaging.core.impl.test.concurrent - contains any concurrent tests for any classes in org.jboss.messaging.core.impl