[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)
Stephen: 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) Regards, Jacques From: Stephen D Green [mailto:stephengreenubl@gmail.com] 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. e.g. class: setVariable { ---- Stephen D Green |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]