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] Groups - TA Anatomy V0.4 (AnatomyTA-v04.doc) uploaded


So there is no pass or fail of the TA I gather
but isn't it written as if there is? That confuses me a bit
(it needs careful wording which I haven't attempted to figure out).

The TA isn't the test case so it doesn't evaluate to anything.
It just gives information to the test case about how it ought
to be evaluated to fulfil spec requirements, say (or on the
test based on the test case based on the TA).

Yet we have determined the beginning of rules to say something like
that a postcondition or precondition which evaluates to false means the test
should evaluate to 'not applicable'. Maybe we just need to extend that rule
explicitly to say

test (or test based on test case) based on TA evaluates to pass if  
(and only if)
either
test based on TA... flow result (if exists) evaluates to true
AND TA postconditions and preconditions and test based on TA..  
triggers (if any)
all evaluate to true
or
test... based on prose evaluates to pass or true (should we make
provision to say which is expected or is that test-case-specific)
or
test... based on pointer evaluates to pass or true (should we make
provision to say which is expected?)

(maybe there needs to be some rule about priority of the above)

then similar rules for how the test would evaluate to fail or 'not applicable'





Quoting Dave Pawson <dave.pawson@gmail.com>:

> On 20/09/2007, stephen.green@systml.co.uk <stephen.green@systml.co.uk> wrote:
>> Quoting Dave Pawson <dave.pawson@gmail.com>:
>>
>> > On 20/09/2007, stephen.green@systml.co.uk   
>> <stephen.green@systml.co.uk> wrote:
>> >
>> >> Isn't the main factor here wanting to make the test assertion into an
>> >> expression with a boolean evaluation (a predicate - I think we need to
>> >> explain that term by the way)?
>> >
>> > Why complicate it Stephen? We want a pass/fail result is simpler?
>> >
>>
>> So are we making it then a convention that true = pass ?
>> i.e. TRUE for a predicate TA result equates to PASS for prose TA narrative
>>
>> If so, maybe we should state that explicitly
>>
>> Don't we need to be clear which parts of the model evaluate to true/false
>> and which parts to pass/fail?
>
>
> Which model?
>
> An assertion == a test. A test must be designed to pass or fail.
> Any use of English beyond that would appear to complicate matters?
> The definition of pass must be explicit within the test document.
> Anything else is a fail.
>
> regards
>
> --
> 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]