Good to see lots of constructive points being made, and glad to see that people are enthusiastic about the general approach. I'll have to wait until monday to give everything a good read through and produce a proper account of what points to take on board. But in general, yes to most points suggested so far.
Tomas - I'm thinking it should test both. At the moment I'm more concered with client-client interop because I'm having problems there (field tables at the moment). I think that in many cases the broker never fully decodes the messages so these problems only show up between different clients. But in general, I think the goal is to fully interop test everything. Johns idea - sounds like a worthy idea but I'd like to keep that in the waiting room for now. I agree with Alan here that the goal at the moment is to get at least some tests up and running quickly. I'll try and bear the idea in mind and ensure that we keep things open enough to add it in one day when we are feeling like we have plenty time on our hands. Rupert On 2/23/07, Alan Conway <[EMAIL PROTECTED]> wrote:
John O'Hara wrote: > Excellent. > > We don't have a common API (yet) so this could be tricky. > > One way might be to write a command processor in each language to process > "psuedo-code" and call the right API functions in that language. > This way we could have a core set of test defintions for any language > -- all > you'd have to do for the new language is write the parser-to-api mapping. In principle I like this idea. In practice I suspect it will suck up time like a sponge leaving little or none to write actual tests. I suggest we focus first on building a small but useful suite of tests described in human text and implement them across the board. Having done that we will probably have more insight into the best way to automate/formalize the framework. I'd prefer to get a working suite of tests then refine the framework and tests than spend months on a framework and still have no interop testing. Cheers, Alan.
