On 11/07/2013 09:56 PM, Irina Boverman wrote:
Currently there are 2 tests, cpp and java/jms, in respective source trees.
qpid/cpp/src/tests/qpid-cpp-benchmark
qpid/java/tools/bin/qpid-jms-benchmark
Both tests use similar options (with a couple of exceptions). They also share
majority of code, the exceptions are calls to qpid-send, qpid-receive and few
other minor differences.
There is a desire to provide one interface for all language implementations (as
well as, extend implementation to other language clients). This goal can be
accomplished in different ways:
Option 1:
Add a thin layer (new test) to check language preference and pass control to
the corresponding test. In this case existing tests are preserved and continue
to exist in the language specific source trees. The disadvantage is that we end
up maintaining similar code in multiple places.
I'm strongly against this option. As you note, the qpid-jms-benchmark is
essentially a copy-and-paste of qpid-cpp-benchmark with one or two lines
commented out (presumably because they break something or aren't
supported?) or tweaked (seemingly just due to different 'executable'
names and again some options not supported) and the recent addition of
options to control the path on which qpid-send/qpid-receive are located.
The latter is a good example of the usual problem with the
copy-and-paste approach, since an update contributed to the original was
not made to the copy. This addition is also designed to allow the same
script to drive different implementations of send and receive.
Option 2:
Consolidate tests into one source and place it in
qpid/tests/src/py/qpid_tests/client/ location. The advantage is reduced
maintenance, the disadvantage is that now one needs all qpid source to run a
specific test.
As above, the scripts are so close that consolidating[1] them is the
obvious choice. However I don't think the qpid/tests location is the
best option. So...
Option 3:
Consolidate the tests into one source and place it in qpid/python. I.e.
consider the benchmark script to be part of (or related to) the python
client much as the qpid-python-test script is.
Since both the existing tests already import qpid.messaging this isn't
actually imposing any significant extra dependency. There are also
python equivalents of qpid-send and qpid-receive.
Providing we keep the ability recently added to qpid-cpp-benchmark to
specify the path to qpid-send and qpid-receive, that test can then be
used to run either c++ or java based equivalents.
--Gordon
[1] In practice I think consolidation is simply a mater or renaming the
qpid-cpp-benchmark, renaming qpid-jms-send and qpid-jms-receive to
qpid-send and qpid-receive respectively, and then modifying those to
accept the options passed in, even if they don't yet actually support them.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
