[Webtest] Running of Webtest scripts in "Browser Playback" mode

[webtest@lists.canoo.com]

Hi Marc,

Thank you for your response.

I agree that this looks more like a "marketing" feature :-). But a requirem=
ent nevertheless :-(

My comments are inline.

Regards,
- Nimesh
Date: Tue, 19 Apr 2005 11:24:29 +0200
From: Marc Guillemot <mguillemot@yahoo.fr>
To: webtest@lists.canoo.com
Subject: Re: [Webtest] Running of Webtest scripts in "Browser Playback" mode
Reply-To: webtest@lists.canoo.com

Personally I think that this is a cosmetic feature that would need a lot of=
 work for a minimal interest. Indeed you can=20
already see in the result reports what the steps have received for answers.=
 Using an appropriate xslt you can for=20
instance present small previews of each result page that appears triggered =
by the onmouseover event on the step.

Nevertheless I agree that this would be a great "marketing" feature.

Some comments remarks to the way you describe:
- it would be quite simple to write an implementation of an IResultReporter=
 that would open the current result page in a=20
browser
Nimesh: Thanks for this tip. I will work on this.

- I don't know JDIC. JRex could be possibility too. Keep in mind that such =
a solution should work not only on Windows=20
systems
Nimesh:JDIC is supported on all platforms. From JDIC I would be considering=
 the "Browser" component. JDIC's browser component can be embedded in a Swi=
ng / AWT application. We can interact with the browser component too. Do no=
t know much about JRex and hence am not sure about it.

- If you want that a setXXX step displays the set value in the page, then i=
t means that you are able to drive a "real=20
browser", and that you can run the tests again it directly rather than agai=
nst htmlunit
Nimesh: We will be running from HtmlUnit only. When we do setXXX we also fi=
re a JavaScript on the embedded Browser component (from JDIC) so that the v=
alue of the field will get set.

- the steps don't trigger an event in ant's meaning because they are run by=
 testSpec, not by ant directly. But I guess=20
that we could send events if needed.
Nimesh: For starters IResultReporter may do the trick. But sending of event=
s or Plug-in based architecture may be a good feature to be considered. Als=
o we may have this IResultReporter itself as the listener for the start of =
even and end of event etc also.

If you really want to develop such an extension, we can adapt webtest to al=
low "plug ins", but I really think that there=20
are higher priorities: a recorder as Mozilla/Firefox plugin is for instance=
 more important for me.
Nimesh: As on today this is one of the requirements that I have. Hence I wo=
uld be working on this. I am not sure whether the recorder as plug-in will =
also solve this problem. If you think that it will solve this problem too, =
then do share your thoughts on the same. I have one worry for recorder as p=
lug-in for a browser and that is, that my application is designed to work o=
nly in IE (maybe intranet application!). If we have plug-in then we would n=
eed to develop for all major browsers. I believe it will be worthwhile if y=
ou take a look at the Browser component of Java Desktop Integration Compone=
nts (JDIC from java.net). In fact they are talking about changing APIs in f=
uture releases of Java.

Marc.


MASTEK
"Making a valuable difference"
Mastek in NASSCOM's 'India Top 20' Software Service Exporters List.
In the US, we're called MAJESCO

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~=
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Opinions expressed in this e-mail are those of the individual and not that =
of Mastek Limited, unless specifically indicated to that effect. Mastek Lim=
ited does not accept any responsibility or liability for it. This e-mail an=
d attachments (if any) transmitted with it are confidential and/or privileg=
ed and solely for the use of the intended person or entity to which it is a=
ddressed. Any review, re-transmission, dissemination or other use of or tak=
ing of any action in reliance upon this information by persons or entities =
other than the intended recipient is prohibited. This e-mail and its attach=
ments have been scanned for the presence of computer viruses. It is the res=
ponsibility of the recipient to run the virus check on e-mails and attachme=
nts before opening them. If you have received this e-mail in error, kindly =
delete this e-mail from all computers.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~=
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~