Re: TAB Comments on Test Assertions for SCA_J Common Annotations and APIsv1.1

[Mike Edwards <mike_edwards@uk.ibm.com>]

Jacques,

The SCA J technical committee thanks
you and the TAB TC for the comments on the SCA_J Common Annotations and
APIs V1.1 Test Assertions.

The following are responses to your
comments:

Issue JAVA-217: [Comment 1] : weak
design: Target is often not well identified, in several TAs.


JCA-TA-2005, JCA-TA-2006,
JCA-TA-2007 and some others. 

It is stated that the target of these statements is incorrect
and that the "real" target should be an SCA runtime.

First, an observation in general that the test assertions
for pretty well all of the SCA specifications are all about verifying
the behaviour of some SCA runtime, so that we take the
view that attempting to define the runtime as the target is pretty
well useless in defining the test assertions.  Instead,
the SCA TCs took the view that what the assertions need to do is to
concentrate on "observables" - things that could
be measured in one way or another.

So taking JCA-TA-2005 as an example of a wider class of
assertions, here the "observable" is the behaviour of a Java
class
that is marked in a particular way - some specific behaviour
is expected when the SCA runtime deals with the class, and it
is this behaviour that is observable - the creation and
initialization in this case.  We believe that it is correct and useful
to 
describe the assertion in terms of this observable behaviour
(and indeed we successfully created a testcase that probes
for this behaviour).

As a result of these considerations, the TC is not minded
to make changes to the assertions along the lines that you suggest.

Similarly, shifting some of the material into the prerequisite
statement is not particularly helpful as suggested does not in these
cases appear to improve the assertions - reporting on
artifacts that don't meet the prerequisites is not the aim of the testcases
at all - the testcases are deliberately set up to have
artifacts that meet certain conditions to probe that such artifacts are
then
handled correctly when presented to the SCA runtime.


Issue JAVA 218: [Comment
2] : (minor) Target is often too fine-grain, leading to convoluted references. 


It is not clear to us that the references
identified in JCA-TA-3005 are in any way convoluted - the target is clearly
identified as the
specific attribute of an element and
the predicate is clearly a statement about the value that the attribute
must have. 
It is not clear to the TC that the offered
alternative formulation is any clearer than the original.


Issue JAVA-219: [Comment 3] : some spec
requirements may need more than one TA

In the case of the SCA specifications,
there is a general blanket requirement that if there are artifacts in error,
then the runtime must raise
an error.  We have taken the view
that in general test assertions are not created for each normative statement
merely to state that an
error must be raised by the runtime
if the statement is violated.  In many cases, negative testcases are
written that do depend on the
runtime raising an error, but this is
ancillary to the "positive" form of the test assertion that is
used.

As a result, the TC is not minded to
create the second negative form of the assertion that is proposed.


Issue JAVA-220:  [Comment 4] :
Target should not be an "event", but an identifiable entity.


As for comment 1, it is taken as read
that it is an SCA runtime is involved, but again, the issue is what is
observable.
In this case the client invocation is
what is observable (what happens in the runtime itself is unobservable,
other than
its impact on the invocation).

The invocation may sound like an event,
but in reality it is a completed process - and so a measurable "thing"
that either
conforms or not.

As for splitting the assertion into
separate parts for the parameters and the returned value, that is something
that a testcase
might choose to do, but it is not a
necessary change for the test assertion.  In reality I think our testcase
checks for both at
the same time.


Issue JAVA-221: [Comment
5] : stronger use of "tags" might help classify TAs based on
targets:  

It is possible that the tags could be
improved, but the suggested ones such as "SCA_Runtime_component"
and "SCA_Runtime_client"
are not appropriate - these do not reflect
anything in the specification.

In general, where a specific element
such as <interface.java/> is the target, then the tags do typically
contain the name of the element. - such
as JCA-TA-3002



Yours, Mike

Dr Mike Edwards		Mail Point 146, Hursley Park
STSM		Winchester, Hants SO21 2JN
SCA & Services Standards		United Kingdom
Co-Chair OASIS SCA Assembly TC
IBM Software Group
Phone:	+44-1962 818014
Mobile:	+44-7802-467431 (274097)
e-mail:	mike_edwards@uk.ibm.com

---

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU