[hyades-dev] Re: external behavior

[Thomas L Roche <tlroche@xxxxxxxxxx>]

Michael.Norman Fri, 17 Sep 2004 14:33:51 +0100
>> External behaviours come in from the U2TP specification, 

>> 
http://www.fokus.gmd.de/u2tp/Related_Documents/UMLTestingProfile_FinalSubmission.pdf

>> The above may not help you unless you have the UML context and
>> additional understanding of the implementation. I've attached a
>> document which I have pulled from an early unfinished white paper
>> and updated to reflect more recent changes. It's not going to be
>> perfectly correct or complete but it may help.

Thanks: I'll take a look as soon as this hits the archive (I'm on the
digest).

Julien Canches Fri, 17 Sep 2004 16:53:57 +0200 (rearranged)
> We are using the external behavior feature in one of our projects.
> Basically, the model specifies that each test has a behavior, and
> this behavior may be either described in the model itself, or points
> to an external resource that describes the behavior. If the behavior
> is an external resource, it is up to the extension to specify this
> external resource format, how it is generated and how it is handled
> for the purposes of code generation and execution.

That doesn't sound too difficult. In the Costello case, the script
format is XML which is written while capturing UI events and run via
JUnit. Presumably any JUnit extension which records is gonna write
captured events (tautology?); it would run its recording either
"directly" (by either recording to JUnit directly, or generating JUnit
test methods/classes from some intermediate format) or by providing an
interface between a JUnit test runner and its scripts (like Costello).

> What you [lose] by choosing the external behavior thing is the
> ability to reuse some UI components (mainly the Test Suite Editor),

Has anyone thought about making this UI extensible? E.g. providing
some way to contribute pages?

> and the compatibility with a model aligned with UML2 concepts.

Part of the goodness (presumably) provided by a tool that persists its
tests as XML (like Costello) is that one can then use EMF to convert
those scripts into UML and Java. Would that provide "model
compatibility" as Julien uses the term?

(Note also that this feeds back to my stated preference for extensions
that record to either XML or Java. Others would need to provide
another means to interact with the model, which sounds non-trivial.)

> But this is not necessarily the "poor man's way" into Hyades,

What I meant was, external behavior sounded like a relatively easy way
for an external (i.e. non-integrated) tool to interface with Hyades,
compared with full-scale integration.

> it allows Hyades to interact with external tools that specify tests
> in a format of their own. In the case of Abbot for instance, you may
> consider either the Abbot Test Suite (the JUnit source) or the .xml
> script as an external behavior of your test. And then, in the
> future, provide some bridge between your external behavior and the
> Test Model's internal behavior.

Could someone point me toward more information about Hyades Test
Model(s)? I'm not seeing anything via google: I assume it's lurking
somewhere in

http://dev.eclipse.org/viewcvs/indextools.cgi/~checkout~/hyades-home/docs/doc.html

but I'm not sure where.

In any case: suppose 3 statements to be true, and to constitute a
(partial) definition of "JUnit extension interfacing":

0 the relevant Hyades UIs were extensible (implementation
  left as exercise :-)

1 a JUnit extension provided an EMF-accessible model of its tests
  (e.g. as Java (JUnit methods and classes) or XML (scripts))

2 either Hyades or the JUnit extension

> provided some bridge between [the extension's] external behavior and
> the [Hyades] Test Model's internal behavior.

What then would be the delta, for users of the composite, between an
interfaced implementation (Hyades plus the JUnit extension, interfaced
as above) and an integrated implementation (a là the proposed
Hyades Sample Tool)?