I've asked Allison to give us someone on p6i who can tell us exactly what tests are appropriate and how they should be coded, assuming she can get someone to agree to it. ;-)

I expect that person should be able to tell us exactly (1) what sorts of tests they want, and (2) how we should build them, and we should Do What They Say. They've been asking for assistance in writing test cases, and we're a perfect group to help do that, since we're going to have to get into & discuss all the edge cases anyway.

But I would imagine that in order to be helpful at all to p6i and QA, we need to make the tests paranoid, tedious, and as encompassing as possible. There may be implementation-specific tests (like memleaks, etc.) we can't help much with, but syntax and behavioral issues, we can.

I think our largest goal should be to be able to organize the tests exactly as the documentation is organized. That doesn't mean anyone will ever see it, other than us and the testers, but if we can coordinate them as a unified effort we can (I hope) make life much easier for the poor souls who will have to track down and add future tests.

So from our standpoint, I would propose we simply have fields in each sub*section like (?):

=test_group general string behaviors

=test conversion to boolean
... code ...

=test conversion from boolean
... code ...

That information can then be sliced out and displayed in whatever formats we need... for example, exported into /t files automatically.

Comments?

MikeL

Reply via email to