I haven't managed to take in all the detail yet (great to see such an active discussion on this topic) but noted a couple of things.
I agree with the feedback on pseudo-code from Alan. I can feel my life slipping through my hands fast enough already :-) Not too sure how to completely get round some system variables being set for the tests to run. For example, if you don't set JAVA_HOME or similar, how can you run the java command ? Should we search through paths - I'm not sure I understand the alternative to some minimal setup. Can Alan or someone shed some light on how the scripts would work without some info about QPID_HOME type stuff ? Once the spec is agreed (probably we need to draw a line in the sand somewhere here ?) I think we need to: - document on the wiki - prioritise some elements - split into compact JIRAs, by technology, so that individuals can pick up the tasks and contribute (we don't have too many all-code-all-clients people on the project !) I'm happy to contribute effort on the legwork for these points to help us get started. This is important for some of my users and I'm keen to see it get easier to ensure interop. It's the bane of my (all of our) life at the moment and something that lets us down a little. Thanks for all your input ! Bfn, Marnie On 2/27/07, Rupert Smith <[EMAIL PROTECTED]> wrote:
On 2/27/07, Alan Conway <[EMAIL PROTECTED]> wrote: > The actual components involved in a given test > run should be determined at runtime by the controller, not baked into > the tests. Just to clear. I'm in agreement with you here. What I'm saying is that coordinator works out what is available to test but dynamically names the results to reflect what was actually tested. The use of the JUnit XML output format is for the convenience of that fact that most automated build servers understand that format and can produce reports from it. It may prove to be convenient to use JUnit to write the coordinator, but not necessary in order generate results with a matching format to that used by JUnit.
