Timothy Bish commented on ARTEMIS-1330:

I have no problem with more tests, so please keep at it.  My concern with 
hacking on existing ones is that they were created to expose a specific issue 
or test a particular big of code so modifications there runs the risk of 
removing the protections that the test provides to prevent an old bug from 
reemerging should the changes alter it to much.

I'd recommend going the route that JORAM did if you want more cross client 
testing of the broker.  You can lift existing tests and group them into a cross 
client suite that has a specific focus on client compatibility on the broker 
which would be good.  Grouping them also makes it easier to keep track of 
what's been tested so you have some direction.  

> [DISCUSS] Run JMS tests over many protocols (through different JMS client 
> libraries)
> ------------------------------------------------------------------------------------
>                 Key: ARTEMIS-1330
>                 URL: https://issues.apache.org/jira/browse/ARTEMIS-1330
>             Project: ActiveMQ Artemis
>          Issue Type: Test
>          Components: AMQP, OpenWire
>    Affects Versions: 2.3.0
>            Reporter: Jiri Danek
>            Priority: Minor
> Currently, there are three sets of JMS tests in Apache ActiveMQ Artemis 
> codebase (that I know of)
> * 
> activemq-artemis/tests/jms-tests/src/test/java/org/apache/activemq/artemis/jms/tests/*
> * 
> activemq-artemis/tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/jms/*
> * 
> activemq-artemis/tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/amqp/*
> The first two are being run only through the Core JMS client, while the last 
> one is being run through Qpid JMS client (with few exceptions).
> It should be beneficial to be able to run all JMS tests through all three 
> protocols that Artemis supports that have a JMS client, these being
> * Core (artemis-jms-client),
> * OpenWire (activemq-client), and
> * AMQP (qpid-jms-client).
> I made an attempt to convert some of the tests to a parametrized test with 
> changeable connection factory. The way 
> {{org.apache.activemq.artemis.tests.integration.persistence.SyncSendTest}} 
> currently does it. See https://github.com/jdanekrh/activemq-artemis/pull/4
> There are the following obstackes
> * Some tests go beyond the JMS standardized APIs and cast the JMS object to 
> specific implementations in their chosen library.
> * Some tests require specific settings on the connection factory, these are 
> not portable across different JMS clients. There will have to be branching 
> depending on the specific factory currently in use, or something...
> * OpenWire client supports JMS 1.1, while Core and AMQP clients are JMS 2.0, 
> some tests will have to be skipped on OpenWire
> * OpenWire client has different semantics of {{receiver.receiveNoWait()}} 
> call; when there are no messages in prefetch cache, OpenWire returns null, 
> while other clients do a round trip to server to check for new messages 
> before giving up.
> There are some improvements which can be considered later, some of these are 
> partially implemented in various places
> * share broker between individual tests
> * use random name or random suffix for created addresses and queues use 
> suffix for queues/topics to ensure isolation
> * have broker uberconfig for all tests, or group tests by config they need, 
> so that reconfiguring broker is limited
> * that also allows tests to run in parallel
> * use random port for acceptor on broker, can run tests even more parallel, 
> and mitigates environmentally caused failures
> I intend to report the failures I found so far (see the code at the link 
> above) and I am reasonably certain they are actual failures. The rest I plan 
> to note in comments here, one test per comment.
> If you happen to have any comments and suggestions how to do this better, I'd 
> be glad to hear them.

This message was sent by Atlassian JIRA

Reply via email to