Hi Rupert, > I'm particuarly interested in getting some constructive feedback on > this. If you disagree with something, please also suggest an > alternative way of doing it, that you feel will be better, more > reliable, easier to implement, or whatever. Thanks.
I think this is a fantastic idea and very needed. Some thoughts: 1- Would this be mostly aimed at testing client-client interop, client-broker interop or both? It seems to me much of the implementation needs you specify seemed to be aimed at client-client, but maybe I'm mistaken. 2- Personally, I'd favor an approach a bit more like Gordon's idea of it being more "centrally controlled" by the controller. Start a client-test process, launch the controller, and do everything from there. It would be simpler to create, run and maintain, I think. 3- I think the initial client to broker connection tests might want to be handled a bit differently (maybe a set of more automated, but regular, integration/unit tests for each client testing different success and failure connection conditions). My main reason for saying this is that I think it might be more awkward to cram the connection-level tests into the kind of structure proposed, and even more if we went with a more central architecture such as the one Gordon proposed. More to the point, one of the basic ideas you propose is already using broker communication and queues to connect the test controller with the individual test clients, meaning already you assume a fairly high-level of interoperability being possible between clients and brokers (and even between clients seeing as how the controller would be written in a single language and each client in a different one). This is also one of the main reasons I ask whether the tests will mostly target client-client scenarios or client-broker scenarios (as for most of the infrastructure it seems to assume the latter already works pretty well). Then again, maybe I'm just missing something :) Tomas Restrepo [EMAIL PROTECTED] http://www.winterdom.com/weblog/
