I have extensively used commercial record
and play GUI tools. Once you have the tool purchased the first thing the vendor
tells you is that record and play test cases are very limited and the best
method is to learn their proprietary language and write/edit scripts. Newer
technologies are moving to a “keyword” technology for GUI testing. This
is very similar to what SAFS has done. http://sourceforge.net/projects/safsdev
Some commercial providers have or already
released product in this area.
From a J2EE point of view, are we thinking
of “in-container” testing such as cactus or “out-of-container”
testing such as mock-objects? We are also using JSF so we would like to
see TagUnit functionality included.
In the existing URL testing how do we address
testing SOAP and XML environments? Could we just add something like
Apache Axis and Xerces and allow testers modify recorded scripts?
Regards,
Jim Saliba
From:
hyades-dev-admin@xxxxxxxxxxx [mailto:hyades-dev-admin@xxxxxxxxxxx] On Behalf Of Julien Canches
Sent: Friday, November 05, 2004
10:19 AM
To: hyades-dev@xxxxxxxxxxx
Subject: Re: [hyades-dev]
Junit-based tools integration Document Update
Michael
Norman wrote on 03/11/2004 22:27:21:
> On the recorder thing, is there aything to
stop us from having an
> external trace model, analogous to an
external behaviour.
There are
existing recording tools around that already have their own recording format.
This is the case for instance for Costello (UI-testing, Abbot script editor),
but also for our own tools (URL tests are generated from a .rec file). If we
want to allow these tools to integrate into Hyades without requiring them to
rewrite everything, we need to support the use of proprietary recording
formats. As far as wording is concerned, I agree that "external trace
model" is a good alternative to "proprietary recording format".
These tools
have the option later to migrate their own model to the trace model, but
requiring them to change to the trace model as a ticket for entering Hyades is
likely to be discouraging.
> Isn't
it
> confusing to have a trace (ie recording) in
the context of a test,
> which
is allowed to be external, whereas a trace for other purposes isn't?
Maybe the
confusion appears by saying trace *ie* recording. Why not keeping the two
notions separate ? A recording is something used for generating a test, whereas
a trace has a more generic meaning. And a trace *may* be a recording.
Julien