OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

tag-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [tag-comment] Comment: a means to associate a test assertion with the setting of a property (or with a value assigned to a variable)



We acknowledge your comment below.


You seem to refer to “property test assertions” as defined in the TA guideline.


It seems  to me that the current TA model is encompassing these – even if not distinguishing these from “requirement” test assertions. The predicate is defined as:

A predicate asserts, in the form of an _expression_, the feature (a behavior or a property) described in the

specification statement(s) referred by the Normative Sources. If the predicate is an _expression_ which

evaluates to “true” over a Target instance, this means that the test assertion target exhibits this feature.

“False” means the target does not exhibit this feature.”


However what you describe is going one step further in having the test to produce an accessory outcome besides the main Boolean outcome (pass/fail) – a kind of by-product of the TA evaluation. This would require to associate the definition of a function to a TA, that calculates this secondary outcome.


Again we’d need to look at solid use cases to be convinced of how useful it would be to add (TA model) a feature that otherwise can be easily added in a test suite as part of the test implementation. The need for such a feature has never emerged from the requirements and scope that the TC has looked at so far.


I see possibly two reasons that could motivate such a feature – yet not sure if that requires a model-level extension (again this is speculative: need real use cases):


1.       A reason to add this to the model would be if such a function plays a significant role in the test assertions logic itself: e.g. used in Prerequisite (or Predicate) of another test assertion. E.g. Prerequisite: TAxyz(target)=’pass’ AND f(target) = 2, where f() is conveniently associated with the definition of TAxyz. But even so,  today you can always define a predicate that makes use of such a function in any TA, by defining the function in the TA itself.  The fact that such a function could be conveniently evaluated as a byproduct of another TA – e.g. a prerequisite TA , is merely an implementation detail relevant to test suite development.

2.       Another reason could be now that we want (some) TAs to actually produce some measures – not just a conformance assessment pass/fail. That would be a fairly significant extension to the TA model, probably more like a V2.0 than a V1.x…


The TAG TC will  discuss this comment in its coming meeting (Wed 28th)





From: Stephen D Green [mailto:stephengreenubl@gmail.com]
Sent: Thursday, August 02, 2012 7:58 AM
To: tag-comment@lists.oasis-open.org
Subject: [tag-comment] Comment: a means to associate a test assertion with the setting of a property (or with a value assigned to a variable)


Comment on Test Assertion Model V1.0


Again, perhaps for a future minor version, I suggest there might be

an extension to the model to cater for the usage described in the

Test Assertion Guidelines V1.0 where a test assertion can be the

means to set a property or a property value (perhaps using the

variable entity to hold the property name). For example, a test

assertion might have extended semantics to allow that the outcome

of a test case based on it, rather than indicate some kind of failure

of conformance, etc., determine that a property be associated with

the test assertion if the test assertion's semantics evaluate to true.

One way might be to add an entity, called something like setVariable,

along with extended semantics to say that if the test case based on

the test assertion evaluates to true (or false in certain cases - see

previous comment) then rather than an outcome of pass, the outcome

will be that a certain value is assigned to the named variable. A weakness

with this approach is that the semantics depend on the existence or non-

existence of this entity (setVariable) in the test assertion so a stronger

mechanism might be preferred.




class: setVariable {
  new-value : string (1)
  name : string (1)
  language : string (0..1)

Best regards



Stephen D Green


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]