[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: Handling of "multi-target" TAs
Looking again at > "In cases where the predicate of a test assertion needs to use more than > one object (part of an implementation), it is possible to consider their > composition as the target. However in many cases, one of them must be > selected as the target, while the other objects are accessory to the > test. Such objects can be referenced in the predicate or prerequisite > using variables." Is there a way we can improve these statements as normative statements, appropriate for the model spec? Firstly, as before we may need to tighten our semantics for 'target', 'object' and 'accessory object'. Maybe we do not need to state these semantics, just to be clear about them as background to the statements we make (?). Secondly we are presenting a choice for how a target relates to a test assertion and to a predicate in particular: Can we improve the two normative statements to this effect? In the second case/choice of approach we offer we have the word 'can' which maybe we need to replace with a normative term such as 'may': "However in many cases, one of them must be selected as the target, while the other objects are accessory to the test. When there is a requirement to select a single object as a target from several objects, the other, accessory objects <b>may</b> be referenced in the predicate or prerequisite using variables." Likewise for the first statement "In cases where the predicate of a test assertion needs to use more than one object (part of an implementation), their composition <b>may</b> be treated as the target." Then the second statement would follow as: "However in many cases, just one of several objects must be selected as the target, while the other objects are accessory to the test. When there is a requirement to select a single object as a target from several objects, the other, accessory objects <b>may</b> be referenced in the predicate or prerequisite using variables." I would tend to add: "Alternatively, the relationship between the objects <b>may</b> itself be treated as a single target." Best regards Steve --- Stephen D Green 2010/1/24 Stephen Green <stephen.green@documentengineeringservices.com>: >> >> "In cases where the predicate of a test assertion needs to use more than >> one object (part of an implementation), it is possible to consider their >> composition as the target. However in many cases, one of them must be >> selected as the target, while the other objects are accessory to the >> test. Such objects can be referenced in the predicate or prerequisite >> using variables." > > I agree, provided the 'must' in "one of them must be" is > not a normative MUST since there are alternatives (as > considering "the composition as the target" or, in my > example just posted, considering the relationship between > two or more objects as the target). > > I do wonder whether we have defined clearly what a 'target' > actually is - the rationale / reason for having one object > in a predicate distinguished and called a 'target'. We have > done so implicitly (something in an implementation which > is a focus for testing and/or subject of the assertion, though > I'm not sure we are clear whether test target or assertion > subject is the primary focus). Should/could this be more > explicit. Why, exactly, explicitly, does a particular object > in a predicate/assertion need to be (and qualify for being) > denoted a 'target'? > > Best regards > > Steve > --- > Stephen D Green > > > > > 2010/1/23 Jacques R. Durand <JDurand@us.fujitsu.com>: >> Stephen: >> >> Looks good to me except for the handling of "multi-target" Tas: >> >> In TA model you add: >> >> "In cases where more than one target is relevant to a test assertion, >> additional targets may be treated as accessory objects and reference to >> these made using variables (see variables section below) and combined to >> form a compound target expression." >> >> I think the following updates are needed: >> - we need to be more assertive on what is to be done (may -> must : the >> user does not have the choice !) >> - also explain a bit more the "multi-target" situation, while avoiding >> to call the additional objects "targets" >> - and finally, the target of such a TA is in general NOT the compound of >> these objects (though it may): >> >> "In cases where the predicate of a test assertion needs to use more than >> one object (part of an implementation), it is possible to consider their >> composition as the target. However in many cases, one of them must be >> selected as the target, while the other objects are accessory to the >> test. Such objects can be referenced in the predicate or prerequisite >> using variables." >> >> I suggest we add a similar note in the Guidelines, a little more verbose >> with a little inline example, say at the end of 4.1 "Complex >> Predicates", since this issue is normally coming up when people have to >> define a predicate using several obejcts: >> >> "Another case where a predicate is more complex is when its conditional >> expression involves more than one part of an implementation(s). In some >> cases it is clear which one of these objects must be considered as the >> target, while others are just accessory objects. >> Consider the following predicate: "the [widget price tag] is matching >> the price assigned to this widget in its [catalog entry]", where price >> tags and catalog entries are both items that must follow the store >> policy (the specification). In that case it may be reasonably assumed >> that the "catalog" content is authoritative over the price tag. The >> price tag can then be considered as the test target, while the accessory >> object may be identified by a variable which is then used in the >> predicate. >> >> Other cases are more ambiguous. >> Consider the following predicate: "the [widget price tag] is matching >> the price that is reported on the related [item in promotion list] at >> the store entrance", where it is not clear at which one of these >> often-changing labels must be incriminated in case of discrepancy >> (although whichever is lower will likely prevail should a customer >> complain). >> >> Three approaches are possible: >> >> (1) Consider a combined target, here a pair [price tag and promotion >> item for widget X] that is identified by the widget ref number. This >> combination will fail or pass the test. >> (2) Select arbitrarily one object as the target, while the other will be >> accessory, e.g. identified by a variable. In a derived test case, a >> predicate failure will inevitably lead to examine both, should the >> accessory object be causing the failure. >> (3) Write two similar test assertions using alternately one object and >> the other as targets." >> >> For review... >> >> Jacques >> >> >> -----Original Message----- >> From: stephengreenubl@gmail.com [mailto:stephengreenubl@gmail.com] On >> Behalf Of Stephen Green >> Sent: Friday, January 22, 2010 11:56 AM >> To: TAG TC >> Subject: [tag] Further iteration (any more changes/discussion?) >> >> Now we do seem to be nearing drafts we can vote on: >> >> Model: >> http://www.oasis-open.org/committees/document.php?document_id=36047 >> http://www.oasis-open.org/committees/download.php/36047/testassertionsmo >> del-draft-1-0-4.pdf >> >> Markup: >> http://www.oasis-open.org/committees/document.php?document_id=36048 >> http://www.oasis-open.org/committees/download.php/36048/testassertionmar >> kuplanguage-draft-1-0-5.pdf >> >> Guidelines: >> http://www.oasis-open.org/committees/document.php?document_id=36049 >> http://www.oasis-open.org/committees/download.php/36049/testassertionsgu >> idelines-draft-1-0-9-6.pdf >> >> If you just want to see the diffs from previous internal review >> >> http://www.oasis-open.org/committees/download.php/36043/testassertionsmo >> del-draft-1-0-4-changes.pdf >> http://www.oasis-open.org/committees/download.php/36042/testassertionmar >> kuplanguage-draft-1-0-5-changes.pdf >> http://www.oasis-open.org/committees/download.php/36041/testassertionsgu >> idelines-draft-1-0-9-6-changes.pdf >> >> Is there more to discuss? Are there more comments? Can we vote on these >> drafts? >> >> I'm not sure exactly how this works but I think we would have to vote on >> the editable source (ODT) versions: >> http://www.oasis-open.org/committees/download.php/36046/testassertionsmo >> del-draft-1-0-4.odt >> http://www.oasis-open.org/committees/download.php/36045/testassertionmar >> kuplanguage-draft-1-0-5.odt >> http://www.oasis-open.org/committees/download.php/36044/testassertionsgu >> idelines-draft-1-0-9-6.odt >> >> and the schema: >> http://www.oasis-open.org/committees/document.php?document_id=35840&wg_a >> bbrev=tag >> http://www.oasis-open.org/committees/download.php/35840/testAssertionMar >> kupLanguage-draft-1-0-3.xsd >> >> and namespace document: >> http://www.oasis-open.org/committees/document.php?document_id=35788&wg_a >> bbrev=tag >> http://www.oasis-open.org/committees/download.php/35788/namespace.zip >> >> >> >> Best regards >> >> Steve >> --- >> Stephen D Green >> >> --------------------------------------------------------------------- >> To unsubscribe from this mail list, you must leave the OASIS TC that >> generates this mail. Follow this link to all your TCs in OASIS at: >> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php >> >> >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]