[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [tag-comment] Minor items on thetestassertionsmodel-1.0-cs-01.pdf
Eric: See my quick personal answers inline <JD> . To be finalized in coming TAG TC meeting, next Tuesday. Thx Jacques From: Eric Johnson [mailto:eric@tibco.com] The SCA Assembly TC was asked to consider endorsing this model, which got me looking at it. <JD> Your last link will be added in coming upgrade of specification.
<JD> Of course it is OK... When you write a test assertions doc for your specification, there are two different kinds of conformance not to be confused, but only one is subject to “conformance clauses” in your document. Conformance of your TAs to the TAG model is not subject to any conformance clause in your document – at best you should refer to the TAG “TA model” specification and state that your TA design is complying with (or following) the TAG model, but there is no need for a formal conformance clause (since your doc is in the position of being an *implementation* of TAG work anyway). If you ever have something like a Conformance Clause in a test assertions doc, the conformance target would be a Test Suite implementing these TAs, or even a test engine as well. A conformance clause would look like: “A test suite is conforming to this set of test assertions for spec XYZ, if it has test cases implementing at least the subset {a,b,c,d,…} of these TAs, and if each test case – when executed on an implementation of XYZ - is producing an output that is in accordance with the intended semantics of the related test assertion (meaning the output should indicate the target is ”not-qualified” if the pre-requisite fails (if any), should indicate “success/pass” if Predicate is true and Prerequiste also if any, should indicate “failure” if Predicate is false and Prerequiste = true if any.) NOTE: you might also define additional things for a TA that extend the TAG model, e.g. add error messages to your TAs, and require in the conf clause that a conforming test suite reuses these error messages.
<JD> We’ll take that comment into account for coming release. In fact we were already considering naming the conformance targets.
<JD> I think you are right – it looks like the use of these keywords is “abusive” in the Introduction – we will discuss this in TC but I think they should just be informal “must/shall”.
<JD> I think you are right – same abusive use of normative keywords, not directly concerning an implementation of the specification.
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]