[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [tag] Proposals for updating the "Anatomy of a TA" section (V0.6):
My last missive inspired Jacques to respond: >Indeed, if we want a TA to do more than just repeat the specification >requirement, it must include something about the nature of the test >operation: >E.g. >(An Error message is send out by MSH in response to receiving an >ill-formed message 'M') AND (The ReferenceId field of the Error message >has same value as the MessageId of M). > >While "true" clearly "indicates" conformance, "false" does not >indicate >non-conformance because the reason for failure may come from the first >member of the boolean conjunction. Now, we may consider various ways to >rewrite this, as one could argue that the above expression mixes two >different things: (a) test preparation + (b) the actual test expression. >For example, put the first member in a "test flow" part instead, or make >it a pre-requisite, or both.... Right. And I thought it was noteworthy that the Unisoft/POSIX reference on Paul's prior-art list [1] defines the "condition" of an assertion as separate from the "cause" (like antecedent vs. trigger). They were thinking of condition as a qualifier up at the profile/module/level/deprecation range, but it may be applicable to the above example as well. The above example also raises the question of whether there should be "variables" or a similar in TAs. In the above example... When MSH receives an ill-formed message M let MID be the MessageID of M MSH must issue an error message E The referenceID of E must equal MID If the above is a TA, it must be qualified as only having a meaningful outcome (pass/fail) if the MSH does in fact issue an error message. It may even be qualified by MSH issuing a specific message. .................David Marston [1] http://www.unisoft.com/glossary.html
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]