RE: [hyades-dev] [JUnit extensions] goals for script/record/play

[Michael.Norman@xxxxxxxxxxxxx]

THis kind-of relates to an old issue of the replayability of the Hyades 
trace model - the old trace/test duality. 

There was a lot of discussion of this and I think the point we got to 
was that the current Hyades Trace Model would be extended to cover 
method data, C/C++ and protocols such as HTTP and would become the 
recording persistence format for the various sample tools.

Then, the traces themselves wouldn't necessarily be used as replayable 
test models, there would be a process of trace-test conversion which 
mapped between them, and obviously allowed you to hang datapools and 
other things around them.

There was a lot of stuff relating to Uber-models, UML2 behaviours, 
external behaviours etc. that surfaced at the point when this was first 
discussed, and someone (e.g. Harm) should confirm that the above is the 
latest position.  I think the last time it came up was in May at the 
F2F.


Mike Norman
Hyades Test Project Lead

-----Original Message-----
From: tlroche [mailto:tlroche@xxxxxxxxxx]
Sent: 14 September 2004 18:32
To: hyades-dev
Cc: grig
Subject: [hyades-dev] [JUnit extensions] goals for script/record/play


Dominique Guilbaud Fri, 10 Sep 2004 14:37:42 +0200
>>>> Open architecture for pluging any JUnit-based testing tools,
>>>> particularly with record features (J.Canches)

Julien: I'm hoping the following doesn't trespass on your area. I'd
just like to clarify our goals WRT this cross-cutting concern, since
they will strongly affect how we evaluate tools in each of the areas
of concern (URL, J2EE, GUI).

Kent D Siefkes Sunday, September 12, 2004 8:48 PM
>>> All of our work on URL test has been on the load testing side,
>>> taking the original JUnit-based HTTP tests and adding an HTTP
>>> proxy recorder with SSL support, test generation improvements,
>>> multi-threaded playback, cookie, page, and SSL support for
>>> playback, and simple SVG reports for capacity and page response
>>> times.

Kent: I'm presuming your recorder writes, and your player reads, to
some format. If so, could you point me toward more information about
that format? If not, could you enlighten?

"Saliba, James" Mon, 13 Sep 2004 16:32:59 -0400
>> We have a number of internal projects using a number of http tools
>> which include, jWebunit, MaxQ and Grinder.

>> I see folks using MaxQ to generate jython scripts and adding XML &
>> soap calls for some web services testing. And Grinder 3 for stress
>> testing.

Grig Gheorghiu <grig@xxxxxxxxxxxxx> 09/10/2004 12:37 AM
> I saw the post on eclipse.tools.hyades about the initiative of
> integrating the jUnit extensions into Hyades. I'm fairly new to both
> Hyades and Eclipse, but I really like what I see. A tool to consider
> for Java GUI testing is Marathon
> (http://marathonman.sourceforge.net/index.html).

> I'm not proficient in Java, as I'm using Python in my day-to-day
> test scripting activities (I work in a QA team for a software
> development company). I know you're not considering including unit
> testing for languages other than Java in Hyades.

All: I assume Gheorghiu's last statement is correct (at least
for the near term--if not, please correct me). However I'm wondering
how folks feel about the following:

0 The importance of record/play. My impression is that (ceteris
  paribus) we prefer JUnit extensions that support record/play to
  tools that do not (e.g. that only provide API with which users can
  write JUnit test methods). I would further assume that, c.p., we
  would prefer tools that provide *both* API and record/play to tools
  that provide only API or only record/play. Does anyone disagree? If
  so, why?

1 The importance of human-writable formats. I consider
  script/record/play to be 3 sides of the same "aspect," since I
  assume that

* one's recorder will hafta record (write) to some format

* one's player will play (read) from that format

* that format should be read/writable by humans, so that folks can
  (minimally) edit their scripts for maintenance or (maximally) write
  their own scripts without needing to record everything

  Does anyone disagree? If so, why?

2 The desirability of supporting script/record/play with procedural
  languages other than Java. My bias is toward persisting to either
  Java (since that's what the workbench currently best supports) or
  XML (since it's

* easily played-back by JUnit: e.g. Abbot provides a ScriptTestSuite
  and ScriptFixture that do this

* more cross-compatible: i.e. one can use XSLT to generate some
  procedural language from XML more easily than one can translate one
  procedural language into another

  ). I'm wondering, are there compelling reasons to persist to a
  non-Java procedural language?

3 The desirability of supporting one script/record/play format for all
  supported tools. Should we prefer to support tools that share some
  common persistence format? Should we provide some common "hub"
  format to which tools could plug in? Or should format not be a
  consideration, at least at this stage?

Your responses are appreciated,
Tom Roche, IBM Rational Developer Model2 Tooling, abbot admin

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