[hyades-dev] Hyades Execution results

["Bonini, Gian Franco" <gian.franco.bonini@xxxxxxx>]

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