[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: Handling of "multi-target" TAs
> > "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]