Alan Conway wrote:
I've started a python framework for writing tests that start/stop
multiple brokers, in particular for cluster tests but could be used for
federation tests etc.
The framework is in python/qpid/brokertest.py, example of use in
cpp/src/tests/cluster_tests.py
Features include:
- separate working dir for each test, named after the test.
- brokers are named, each broker has own data dir and log files under
test dir
- easy to start brokers, clusters and other executables (e.g. the
cluster_tests use the sender/receiver binaries)
- unique cluster names, can run multiple instances on the same subnet
- kills all started processes during teardown, verifies that status
matches test expectation (exit ok, exit failure or still running)
- can register other resources for cleanup on teardown - currently
anything with a stop() method but we can easily extend that.
- some convenience methods for declaring queues, sending/receiving
messages using the new python API, this set will grow
I'll be using this for cluster testing I'll be happy to help anyone who
wants to use it for other purposes, contributions welcome!
This sounds like some really useful stuff, and I look forward to playing
with it, but one issue I think we need to sort out is its location, or
possibly just the general use of the python/qpid dir.
Unfortunately the python/qpid directory is becoming a bit of a dumping
ground for anything that happens to be written in python, when really it
started out as the home of the python AMQP client. This makes it rather
difficult to generate correct API-docs as random non-public utilities
can easily slip in. As you can imagine it also makes it difficult to
write a proper README for the directory.
So I think we need to make a bit of a decision on what the python
directory is for. If we want to keep it as a place for anything that
happens to be written in python then I need to move the python client
elsewhere, and if we want to decide that the python client stays here,
then we need to be a bit more disciplined about checking in code that
isn't directly part of the python client.
Personally I think the top level division by language is showing its
limitations, and we should probably have some additional top level
locations for generically useful stuff like this to live, e.g. an area
for project-wide testing stuff that isn't really related to one
particular language silo.
--Rafael
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
