Hi,
another way would be to represent the webtest state as xml, and use this
description as the current response?
<browser>
<window>
<form name="login">
<element name="login" type="text"/>
</form>
</window>
</browser>
That way verfiyXPath could be used to do some additional tests on the
dump-information on a more abstract level.
dumpResponse would be more useful when creating a webtest script, as one
no longer must dig the fetched html page and one sees the output on the
console. saveResponse="debug/DOM" would be more useful to find out why
some already existing tests break. Especially when run by a continous
integration tool.
lothar
On Mon, Dec 05, 2005 at 09:31:39PM +0100, Marc Guillemot wrote:
> Hi Denis,
>
> it could be an idea to have saveResponse="DOM" or something like that to
> dump the current state of the parsed page to a file (it is html).
>
> Concerning my other propositions I think that a small output to the log
> would be better than generating an html or text file for it. The purpose
> would be to bring help in some situations where we already look at the
> debug messages and it would be faster to use as well as more interesting
> along with the other debug information.
>
> Marc.
>
> Denis N. Antonioli wrote:
> >Hi
> >
> >a very interesting proposition indeed.
> >
> >But I wonder if a new step is the best solution?
> >A new step is easier to implement, but is it really practical in daily
> >use?
> >
> >How about overloading the exisiting configuration option saveResponse from
> >its present boolean yes/no to a level-based concept, as we know it
> >from, e.g, log4j
> >
> >For example:
> >saveResponse=no -> as today
> >saveResponse=yes -> as today
> >saveResponse=debug -> as today, plus according to your proposal in a
> >2nd file
> >
> >
> >What do you think?
> >
> > dna
> >
> >On 5 déc. 05, at 11:30, Marc Guillemot wrote:
> >
> >>>Maybe we find even more information that would be helpful and
> >>>isn't available in the log.
> >>
> >>
> >>Yep
> >>
> >>1- the current opened windows with their frames
> >>giving information on the opened windows, the title and the url of
> >>the documents as well which one is considered by webtest as the
> >>current one.
> >>
> >>E.g.:
> >>
> >>Current windows:
> >>* - Choose user (http://foo.com/myapp/chooseUser)
> >> - My great app (http://foo.com/myapp/start)
> >> - menu "Left menu" (http://foo.com/myapp/left)
> >> - main "Main content" (http://foo.com/myapp/main)
> >>
> >>2- the forms in the current document with their controls and how they
> >>can be identified by setXxx steps:
> >>
> >>E.g.:
> >>
> >>Forms in http://foo.com/myapp/main:
> >>* - loginForm (http://foo.com/myapp/doLogin)
> >> - username (text) can be found by name (username) or id (loginField)
> >> - userpasswd (password) can be found by name (userpasswd) or id
> >>(loginPasswd)
> >> - submit (submit) can be found by name (submit)
> >> - searchForm (http://foo.com/myapp/search)
> >> - freetext (text) can be found by name (freetext)
> >> - submit (submit) can be found by name (submit)
> >>
> >>3- The same thing for links
> >>
> >>etc
> >>
> >>in short, a debugger for webtest ;-)
> >>
> >>Marc.
> >>_______________________________________________
> >>WebTest mailing list
> >>[email protected]
> >>http://lists.canoo.com/mailman/listinfo/webtest
> >
> >
>
> _______________________________________________
> WebTest mailing list
> [email protected]
> http://lists.canoo.com/mailman/listinfo/webtest
--
Lothar Märkle - [EMAIL PROTECTED]
Netpioneer GmbH - Beiertheimer Allee 18a - D-76137 Karlsruhe
Tel: 0721 / 9 20 60 43
Fax: 0721 / 9 20 60 30
_______________________________________________
WebTest mailing list
[email protected]
http://lists.canoo.com/mailman/listinfo/webtest
