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

[Harm Sluiman <sluiman@xxxxxxxxxx>]

Yes a review of these in the f2f is
very appropriate.

There are calls being run by Marius
on the subject of adding protocol etc. support to the trace model, starting
with required parameter capture. As that comes on line the http recorder
will have to migrate to that model. The base spec is due in the 3.1 time
frame, and the impl is targeted in 3.2 based on our plan.

UML2 is still a long way out with what
adoption really means and U2TP to be spec'd for 3.1. This work is not on
track at this time. The UML2 model project is also not yet confirmed with
dates so this topic is going to remain long range.

Dominique is driving the alignment of
our test environments to JUnit for the Java space with the first cut spec
in 3.1 and the impl currently targeted for 3.3.

So once the model is figured out for
at least capture we can start the work to record to the model and then
the steps of creating tests from recordings. Each "recorder"
that is built to create the skeleton of a test needs to be done in this
context and any requirements they drive will need assessment. It is this
multiplicity that makes this a somewhat tedious at times effort of compromise
;-)

Thanks for your time.
--------------------------------------------------------------------------
Harm Sluiman, STSM,  
phone:905-413-4032   fax: 4920  
cell: 416-432-9754
mailto:sluiman@xxxxxxxxxx
Admin : Gabrielle Chapman chapmaga@xxxxxxxxxx  Tie: 969-2323

Michael.Norman@xxxxxxxxxxxxx
Sent by: hyades-dev-admin@xxxxxxxxxxx

09/15/2004 06:52 AM

Please respond to
hyades-dev

To	hyades-dev@xxxxxxxxxxx
cc	grig@xxxxxxxxxxxxx
Subject	RE: [hyades-dev] [JUnit extensions] goals for script/record/play

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

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