[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [hyades-dev] [JUnit extensions] goals for script/record/play
|
Tom,
I think I understand Harm's response and I think it's what I thought the
plan was from the Hyades project side. In other words the sample tools
record into the trace model, the tests are generated from the traces,
the editor and the codegen operate relatively generically on the tests.
So this would give us a generic way of dealing with at least some of
these types of tools e.g. Abbot & Costello by mapping their existing
persistence formats through to trace models describing interactions with
the APIs and then running our generic editor and generic codegen on
them. All we need is to get the Hyades trace stuff to act as a generic
recorder and we've subsumed the tools. We can then release the thing
inside RCP and call it Abbot & Costello ;-)
However, there's another way of doing this which is to take the tools
more or less as is with their own editors recorders and replay engines
and integrate them as external behaviours which happen to fire some
stuff back into the execution history.
Which of these were you thinking of? Your postings to hyades-dev and
abbot-users give entirely different impressions of this!
Mike
-----Original Message-----
From: sluiman [mailto:sluiman@xxxxxxxxxx]
Sent: 15 September 2004 15:18
To: hyades-dev
Cc: grig
Subject: RE: [hyades-dev] [JUnit extensions] goals for
script/record/play
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
