Re: Handling of "multi-target" TAs

[Stephen Green <stephen.green@documentengineeringservices.com>]

I'd like to add a further approach in the Guidelines - with
a relationship between objects, making the relationship
itself the target. Then with a little rewording we'd get:

"Another case where a predicate is more complex
is when its conditional expression involves more than
one part of an implementation (or implementations).
In some cases it is clear which one of these objects
must be considered the target, while others are just
accessory objects.

Consider the following predicate: "the [widget price tag]
matches the price assigned to the widget in its [catalog
entry]", where price tags and catalog entries are
both items that must follow the store policy (in effect
the specification). In this 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] matches the price that
is reported on the related [item in list of today's special
offers] at the store entrance". Here it is not clear which
one of these often-changing labels must be incriminated
in the case of a discrepancy (although whichever is lower
will likely prevail should a customer complain).

The following approaches are possible:

· Consider a combined target, here a pair [price tag and promotion
item for widget
X] that is identified by the widget reference number. This combination
will fail or pass the test.
· Consider the relationship between objects to be the target, here
[the difference between
the price tag and the promotion price for widget X] which must be zero to pass
the test.
· Select arbitrarily one object as the target, while the other will be
an accessory, for example,
identified by a variable. In a derived test case, a predicate failure
will inevitably lead to the
examination of both, should the accessory object be causing the failure.
· Write two or more similar test assertions using alternately one
object and then the other as the 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
>
>