RE: [hyades-dev] Hyades Execution results

[Michael.Norman@xxxxxxxxxxxxx]

This stuff about Hyades endorsing the use of proprietary BLOBs in the 
data model, makes me extremely nervous. Do we really need to solve this 
now? At this stage fo the game the execution history is being 
overloaded. Can't we wait until the trace models are richer and more 
coordinated and we can trace all the elements in the behaviour 
(Datapools, SUTs, Arbiters, internal behaviorual elements such as loops) 
in a coordinated linked fashion?  

If we need to solve this problem now, at this stage I think the 
requirement relates primarily to external behaviours, or to things 
driven off the facade.  If this is the case then my intuition is to use 
the facade (it's kind-of what it's for) and for external behaviours the 
test type (it's our gating mechanism across the external behaviour "cat 
flap" in the current model), rather than building a whole bunch of 
additional proprietary rat-holes in the data models.

If we do go ahead with this BLOB stuff, we're doing something very 
similar to MIME, and the right thing to do is (as MIME does) to specify 
the nature of the BLOB not the way it is to be processed.  With MIME 
it's up to the browser to invoke the right plug-in.  The point about the 
proposed UI provider hook is it is not generic. It's not even fit for 
our future purposes in Eclipse.  We are pre-judging the processing we 
will have to apply to these BLOBS. Who knows the things we may have to 
do with them in the future.  I certainly envisage invoking a virus 
checker on them :-) 



Mike



-----Original Message-----
From: gian.franco.bonini [mailto:gian.franco.bonini@xxxxxxx]
Sent: Friday, March 19, 2004 1:40 PM
To: hyades-dev
Subject: [hyades-dev] Hyades Execution results


Hi,
 
Some follow-up to yesterday's test model meeting.
 
I can see different use cases for a UI provider associated to the 
execution events: 
1. differentiate between e.g. the various start events (start loop, 
start test execution, etc)
2. allow flexible text display for internationalization purposes
3. allow test-tool-specific icons and texts (e.g. invocation of a JUnit 
test shown in a different format from an HTTP test)
4. allow icons and texts to depend e.g. on the behavior element 
associated with the execution event.
 
Is that roughly accurate? Am I missing any important use case? 
Apart from some quibbling on minor points, I agree that for 1-4 
something like the suggested extension point is needed 
I still have a couple of remarks:
* It would be nice to solve Problem 1. in the standard viewer, however 
e.g. loop is a façade concept and therefore not fully generic. Could we 
implement - as part of the façade - a UI provider to display the 
different start events according to the element that has been started? 
(Execution Event has a reference to an Interaction Fragment which could 
be used to identify the correct façade element). That would already 
improve the appearance of the typical execution result (of course tests 
that use the façade  could still override the default UI provider for 
more specific texts/icons) 
* Are there any plans to support I18n of execution results in a generic 
way? We're probably not the only ones to think of it as a valuable 
addition 
* To solve 3. and 4., the UI provider could be also triggered not by an 
attribute in the execution event but by the test suite type. In fact, 
unless there is interoperability between vendors, one way or the other 
won't make any difference. 
 
One use case that is relevant to us is that we might want to use UI 
providers from third-party tools in environments other than Eclipse 
(e.g. in a browser). That would be feasible as long as the provider 
interface does not explicitly refer to Eclipse-specific (SWT-based) UI 
elements. What's the signature of the UI provider methods? getLabel can 
return a string, that would be fine. It would be nice if getIcon could 
also return some SWT-independent object.  
 
Concerning the other topic under discussion (adding to each execution 
event a collection of triplets name-type-value):
We definitely have use cases for that. The points that Martin mentioned 
in a previous post could be for example accommodated as follows:
* Reference to the SUT: we might add a triplet name="SUT", type=<the 
specific SUT Type>, value=<some (XML-)String identifying the SUT element 
relevant to the execution event> 
* Reference to datapool entries used as input: add a triplet 
name="IN_DATA/variable name", type = "Datapool", value=<some 
representation of a datapool cell or record, or a reference to it> 
* Non-datapool variables after a given event: add a triplet 
name="OUT_DATA/variable name", type = "variable type" value = "<some 
representation of the value>" 
We'll have to adopt namespaces and hierarchical names to overcome the 
lack of deep structures, but as a first step I guess it will do. Once 
e.g. the SUT is modelled (or if other stakeholders agree that a 
reference to the SUT is a meaningful thing to have), the SUT-triplet 
could be promoted to model attribute in its own terms, maybe in a more 
suitable form.
 
Gian Franco
 
-------
Gian Franco Bonini
SAP AG
 

_______________________________________________
hyades-dev mailing list
hyades-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/hyades-dev