I don't think the test clients will need to use JUnit/CppUnit/WhateverUnit. Mostly they will just be fairly simple scripts that react to instructions sent by the coordinator. Although, having said that, you could use *Unit if you like. I'm just not sure it adds anything, because these clients won't do anything when run on their own. They need the coordinator to push them along.
The coordinator itself is a different story. I've sketched an outline for it in Java built on top of JUnit. Trying to use JUnits existing TestSuite mechanism, and ability to locate tests in *Test classes. A little bit of adaption perhaps needed to dynamically name the tests, or to run the same test case many times accross differnt combinations of clients. A root test case called something like InviteTestCase to provide common code to do the invite and gather reports, and provide convenience methods for common tasks etc. Here JUnit adds a lot as a convenient framework to base this on. I'll aim to get this skeleton code, and skeleton code for a java test client checked in before fleshing it out. That way, other test clients can copy the same structure. Spec updated, in response to Gordons comments. http://cwiki.apache.org/confluence/display/qpid/Interop+Testing+Specification Rupert On 3/7/07, Gordon Sim <[EMAIL PROTECTED]> wrote:
Alan Conway wrote: > Don't forget there are *two* points for centralizing test control code. > One is the co-ordinator, the other is the test runners that will > actually be running the tests. My view is that anything that can be done in the co-ordinator should be done there. The test runners only centralize code for one language; the co-ordinator centralizes code for the entire framework.
