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


Help: OASIS Mailing Lists Help | MarkMail Help

sca-j message

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

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


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

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