2009/11/12 Rafael Schloming <[email protected]> > 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. > > -
+1 As I've said before, organising things soley by the language something is written in makes no sense to me... If I want to look for a utility why should I need to know what language it is written in... If I find a need for some sort of general utility am I likely to hunt through every language directory to see if such a tool exists already... or just build my own version in the language I am most familiar with? Making clearer functional boundaries in the structure (even if only separating out tools and utilities from the clients/brokers) can only help us in bringing more re-use and uniformity to the project IMHO Cheers, Rob -- Rob
