Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [hyades-dev] Junit-based tools integration Document Update

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


Back to the top