qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rupert Smith" <rupertlssm...@googlemail.com>
Subject Re: Draft Interop Testing Spec - Please Read
Date Wed, 07 Mar 2007 15:09:12 GMT
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.



On 3/7/07, Gordon Sim <gsim@redhat.com> 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.

View raw message