Re: [tag] Thread: TA modeling - RE: [tag] TA Model still weak ontests of structure?

[stephen.green@systml.co.uk]

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

> On 26/09/2007, stephen.green@systml.co.uk <stephen.green@systml.co.uk> wrote:
>> An example of how I would see this working:
>
>> -------------------------------------
>>
>> Test Assertion:
>> BP1309
>>
>> Prerequisites:
>> BP1701
>
> This is part of the test flow, not the individual test.
> If it is a true dependency, then the test flow control must
> code this in. Right logic, wrong place.
>
>
>>
>> Trigger:
>> [Not specified]
>
> In which case not required, other than to say when the test runs?
>
>
>>
>> Test Expression:
>> For a candidate envelope containing a soap:Body element the
>> soap:Envelope does not have direct children after the soap:Body element
>>
>> Outcome:
>> The Test Expression MUST be true
>
> Badly designed? What expression?

'Test Expression'

in other words

"For a candidate envelope containing a soap:Body element the
soap:Envelope does not have direct children after the soap:Body element"

That's what I've merely labelled/headed 'Test Expression' without changing
the substance of the content of the TA. It could be called 'Assertion
Expression'. It is the TA prose turned into an expression which evaluates
to true or false.

In fact the alternative we are accommodating (with a section called something
like 'Assertion Description') is perhaps just an item of atomic requirements
lifted from the spec. That is preferred by some to a boolean expression since
there is less of a requirement to provide alternative, perhaps lossy, wording
to the spec's normative prose. Another alternative is a reference to such
in the spec itself. The 'Test Expression' or 'Assertion Expression' I'm
proposing is distinct from 'Assertion Description' in that it is converted
logically into a predicate (expression evaluating to true or false). This
conversion removes something, most likely some information about the outcome
of either true and/or false in the test(s) based on the assertion. This has
been proposed to be called 'Outcome' and I am proposing it be that extra
information (and no more) expressed in relation to the predicate
'Test Expression'. The way this is done I don't think we have to specify
except to give an example - in this case my example is "The Test Expression
MUST be true" (meaning the predicate in the section 'Test Expression' is
required to be true - an alternative form of wording if the 'MUST' keyword
is to be avoided, say).

> What variables.

The example might seem incomplete (especially if you are looking for an actual
test) but this is a real world example form an set of TAs for an actual
profile.


> A test must test something, some test outcome must be measured
> in some way.

Again, I'm not trying to establish best practise for actually writing
the test assertion content, just a sensible, simplest best-fit structure
for a general TA which meets, as much as possible for such a structure,
the breadth of prior art examples on which we are focusing.

I hope the above clarifies my proposal. Not so hopeful it will persuade :-)

Regards

-Steve

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