Hi All, Martin - thanks for taking the time to think about how we could be less bunkered :-)
'Fraid I agree with the others that the svn revamp is probably not a good way to go, sorry. However, it has prompted a really useful discussion about how we might achieve better clarity around requirements/testing/traceability/project goals. This has always been a tricky process, at least in goal setting terms, as we're not driven by a common commecial goal as we would be a for-profit project environment. Makes it quite hard sometimes to agree the scope of things and so we've tended to be more organic I guess. However, I do still think there's value to be had in defining a set of requirements, even if we just scrub up our JIRAs and scope them for M3. I've always been heavily in favour of describing the matching tests in any resolution details too (not necessarily test driven, but at least test proven ... not that I'm claiming the moral high ground in any way). I also think we ought to consider a change to our lifecycle for JIRAs with the developer completing the work handing over to another developer to test and 'close' the JIRA. This should improve project quality imho ! I guess our first focus should be building M2 and then we should, as Martin suggests, take the chance to look at where we are vs where we want to be, both in project features/code maturity/test coverage/interop terms but also from an incubator graduation perspective (project surround etc). Bfn, Marnie On 4/23/07, Martin Ritchie <[EMAIL PROTECTED]> wrote:
On 23/04/07, Alan Conway <[EMAIL PROTECTED]> wrote: > On Fri, 2007-04-20 at 21:11 +0100, Robert Godfrey wrote: > > Hmmm... How do you test your tests are testing the right thing? > > > > 1. write requirement in English > > (1a. agree on requirement) > > 2. write test > > 3. write code that is going to be tested :-) > > > Absolutely, you can't map requirements to tests until you know what the > requirements are. > > > I've seen so many tests that tests that the code does what it does... > > Verifying requirements, particularly with people who don't read/write code > > is a valuable exercise in itself. The AMQP spec is obviously our major set > > of requirements, however we also have Qpid specific requirements. > > Again absolutely. In an ideal world developers would write unit tests > for their code, *users* would write acceptance tests for requirements. > I've never seen that happen in real life, but we have quite a few Qpid > team members from user organizations which is good, so hopefully we can > at least pick up some good quality user requirements in English and get > some developer input on test writing from people close to the action. > > Cheers, > Alan. I agree that we really need to focus on testing (unit, functional and interop). It is interesting to see every one's opinion on a reorganisation. I remember the pain we had with our maven reorganisation but that was more to do with getting the tool to work. I'm not driven to have a particular layout especially when development tools these days present everything as one view anyway. We do currently have an mix between functional and language structure. The gentools are for all languages rather than there being a c++/gentools or a java/gentools. Thinking about the interop testing system that we are in the process of building. I would have thought it would have been good to have it together rather than spread across language specific folders. Thanks for the thoughts, guess as a group we don't really want to move things around just now. As long as we do not force our developers to build entire products they do not wish/need with our current setup then I have no real problem. Just thought I'd mention it while we had a brief pause between AMQP versions. Cheers -- Martin Ritchie
