OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

tag message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [tag] some thoughts and comments from reading a month worth ofmessages


On 22/09/2007, stephen.green@systml.co.uk <stephen.green@systml.co.uk> wrote:

> Yes, this is like how I was thinking with the metadata attribute like
> 'isTrueFalse'. There would be a problem with 'isPassFail' since it
> might be more than just pass and fail - it might be pass fail or error
> or it might be pass fail error or inconclusive or even pass fail error
> inconclusive or inapplicable. It is in some cases determined by the
> logic of the TA (e.g. depending on whether there are clear conditions
> to mean a test can be inapplicable/inappropriate) and in most cases
> determined by the test methodology, to which the TA should be agnostic.

Another scope issue?
What happens when a test passes / fails (boolean) is an agreement
with the spec author. If the test has an error (program logic, say)
then it must fail.

If it is inconclusive, it is badly designed.
What happens after a pass/fail is an issue for program flow.



>
> Maybe the guideline could be that if the value is not boolean (isTrueFalse
> = false) then it is to be assumed that the outcomes will include pass
> and fail but not exclusively (other values may be dependent on factors
> out of scope).

I'd propose that the test is invalid. Define the test pass conditions,
all else is a fail.








-- 
Dave Pawson
XSLT XSL-FO FAQ.
http://www.dpawson.co.uk


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]