Request-Recorder (was: RE: [Webtest] Testdata)

Torben Tretau webtest@lists.canoo.com
Tue, 22 Oct 2002 16:49:19 +0200


Hi,

I would contribute too where I can.. 
This solution makes sense and could be very helpful for users to
quickly build up testcases..

How should this be solved, should the User open a view in his
browser and we use HTTPUnit to catch the same page?
Or the solution as it is done in MaxQ, mentioned in a mail here..
With building up a proxy?
I do think about another version by using the new filters from
servlet 2.3 spec.. ?
Any ideas..?

Ok, perhaps it's worse to sleep one night over it.. ;-)

Torben

The following message was sent by "Dierk Koenig" <dierk.koenig@canoo.com> on Tue, 22 Oct 2002 14:54:47 +0200.
> Hiall,
> 
> for ease of test creation I would contribute to an effort
> that tries to give the user a suggestion on what properties to
> test on specific page.
> 
> After retrieving a page we could generate
> - possible verification steps for named elements
> - possible clicklink steps for links on the page
> - possible setinputfield steps
> - possible clickbutton steps
> 
> the user would then choose from the sugestion and do some
> manual post processing like replacing literal values
> with properties.
> 
> Is anyone interested in this?
> 
> cheers
> Mittie
> 
> 
> 
> > -----Original Message-----
> > From: webtest-admin@lists.canoo.com
> > [mailto:webtest-admin@lists.canoo.com]On Behalf Of Torben Tretau
> > Sent: Dienstag, 22. Oktober 2002 13:56
> > To: webtest@gate.canoo.com
> > Subject: RE: [Webtest] Testdata
> >
> >
> > Hi,
> >
> > I will think about this, and how to realize this some days..
> > Perhaps some day/night I will try it out.. ;-)
> >
> > The DB solution means easier test generation from
> > non-coders to me, via excel or sql-frontend-tools..
> > After description for the testcase they have a table with
> > input values for each page they have to fill..
> >
> > You mean performance of any solution could be a problem?
> >
> > Torben
> >
> > The following message was sent by "Dierk Koenig"
> > <dierk.koenig@canoo.com> on Tue, 22 Oct 2002 10:44:06 +0200.
> > > Hi,
> > >
> > > I guess your idea is worth trying.
> > >
> > > For me it boils down to the question what representation of
> > > key/value pairs is the easiest to manage.
> > >
> > > The DB solution would have all the typical benefits of a DB, i.e.
> > > ad-hoc queries, centralized administration, and so on.
> > >
> > > The file solution has the "power of plain text", such that your
> > > "test resources" can be managed the same way as your test.xml.
> > > In case of the webtest selftest the external resouces are
> > > managed via cvs, assuring you have them in sync with the
> > > xml file versions and allowing for distribution to users and
> > > contributors.
> > >
> > > Maybe some performance issues need to be considered as well.
> > >
> > > cheers
> > > Mittie
> > >
> > > > -----Original Message-----
> > > > From: webtest-admin@lists.canoo.com
> > > > [mailto:webtest-admin@lists.canoo.com]On Behalf Of Torben Tretau
> > > > Sent: Dienstag, 22. Oktober 2002 10:11
> > > > To: webtest@gate.canoo.com
> > > > Subject: RE: [Webtest] Testdata
> > > >
> > > >
> > > > Hi,
> > > >
> > > > that is something in the direction I thought about. Instead
> > > > of property files I had a database-table in mind..
> > > >
> > > > For example I declare my jdbc datasource and table for a testSpec,
> > > > so I could give my setinputfield-tag the table column I want to
> > > > use for it.
> > > > The testspec will then be executed for each table row. Tables could
> > > > be filled with imported data from excel sheets, xml, merged from
> > > > other databases, filled in manually or so ..
> > > >
> > > > I mean property-files could be difficult to handle with time..
> > > >
> > > > Bye,
> > > > Torben
> > > >
> > > > The following message was sent by "Dierk Koenig"
> > > > <dierk.koenig@canoo.com> on Mon, 21 Oct 2002 18:01:04 +0200.
> > > >
> > > > > Hi, my two pennies to the issue:
> > > > >
> > > > > We made some good experience with having this kind of data in
> > > > > property files such that there would be 2 property files
> > > > > A and B where
> > > > > A would contain
> > > > > user=user_c@b
> > > > > and B would contain
> > > > > user=user_d@a
> > > > >
> > > > > the webtest code than just uses ${user}.
> > > > >
> > > > > The samples under http://webtest.canoo.com/webtest/samples/
> > > > > have some elaborate examples for that approach, also using
> > > > > "includes" to avoid duplication. Look at the "includes" and
> > > > > "properties" folders.
> > > > > The sample Application shows the combination of
> > > > > different user groups with multiple languages without
> > > > > duplicating the common code.
> > > > >
> > > > > cheers
> > > > > Mittie
> > > > >
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: webtest-admin@lists.canoo.com
> > > > > > [mailto:webtest-admin@lists.canoo.com]On Behalf Of Torben Tretau
> > > > > > Sent: Montag, 21. Oktober 2002 15:26
> > > > > > To: webtest@gate.canoo.com
> > > > > > Subject: RE: [Webtest] Testdata
> > > > > >
> > > > > >
> > > > > > Hi,
> > > > > >
> > > > > > ok, that is good for testing persistence.. I mean with
> > testdata that
> > > > > > I have different settings of data that my web-application should
> > > be
> > > > > > tested with.
> > > > > > For example to test logins I could use a table with
> > user_c@b, user_d@a
> > > > > > with passwords and so on..
> > > > > > Testing the same fields with different test-data means
> > > > writing test-steps
> > > > > > for each of them..
> > > > > >
> > > > > > Torben
> > > > > >
> > > > > > The following message was sent by EPugh@upstate.com on Mon, 21
> > > > > > Oct 2002 09:01:41 -0400.
> > > > > >
> > > > > > > I like to use DBUnit..  DBUnit has a series of Ant tasks that
> > > > > > allow you to
> > > > > > > update the database.  This works very well if you have a
> > > > "test" database
> > > > > > > where you can delete/modify/insert data to your hearts contents.
> > > > > > >
> > > > > > > Here is an example test.
> > > > > > >
> > > > > > > Ant Script:
> > > > > > > <target name="exportOptInEmailsToBrowser">
> > > > > >
> > > > > > >   <dbunit
> > > > > > >     driver="${sql.jdbcdriver}"
> > > > > > >     url="${sql.url}"
> > > > > > >     userid="${sql.username}"
> > > > > > >     password="${sql.password}">
> > > > > > >         <operation type="MSSQL_REFRESH"
> > > > > > src="data/exportEmailsToBrowser.xml"
> > > > > > > format="flat"/>
> > > > > > >   </dbunit>
> > > > > > >
> > > > > > >   <testSpec name="exportOptInEmailsToBrowser">
> > > > > > >     &sharedConfiguration;
> > > > > > >     <steps>
> > > > > > >       &invokeHome;
> > > > > > >       <clickbutton stepid="Click link to Go To Export Email
> > > > Addresses"
> > > > > > >                 label="Export Email Addresses"/>
> > > > > > >       <verifytitle stepid="Make sure we are on the Export Page"
> > > > > > >                 text="Export Email Addresses"/>
> > > > > > >       &verifyNoError;
> > > > > > >       <setinputfield stepid="set download type to
> > browser window"
> > > > > > >         name="downloadtype"
> > > > > > >         value="1" />
> > > > > > >       <setinputfield stepid="set optin radio button"
> > > > > > >         name="exportType"
> > > > > > >         value="optin" />
> > > > > > >       <clickbutton stepid="Click link to Export Email Addresses"
> > > > > > >                 label="Export Email Addresses"/>
> > > > > > >       <verifytext stepid="Make sure we have a title"
> > > > > > >                 text="email id,email,optin"/>
> > > > > > >
> > > > > > >       <verifytext stepid="Make sure we exported good data"
> > > > > > >                 text="1exportOptInEmailsToBrowser@test.com"/>
> > > > > > >
> > > > > > >       <verifytext stepid="Make sure we exported good data"
> > > > > > >                 text="3exportOptInEmailsToBrowser@test.com"/>
> > > > > > >
> > > > > > >       <not stepid="make sure opted out people are not included">
> > > > > > >         <verifytext stepid="Make sure we have not exported
> > > > opted out"
> > > > > > >                 text="2exportOptInEmailsToBrowser@test.com"/>
> > > > > > >       </not>
> > > > > > >     </steps>
> > > > > > >   </testSpec>
> > > > > > > </target>
> > > > > > >
> > > > > > > exportEmailsToBrowser.xml file for DBUnit:
> > > > > > >
> > > > > > >
> > > > > > > <dataset>
> > > > > > >
> > > > > > >   <EMAIL EMAIL_ID='1'
> > EMAIL='1exportOptInEmailsToBrowser@test.com'
> > > > > > > OPTIN='1'/>
> > > > > > >   <EMAIL EMAIL_ID='2'
> > EMAIL='2exportOptInEmailsToBrowser@test.com'
> > > > > > > OPTIN='0'/>
> > > > > > >   <EMAIL EMAIL_ID='3'
> > EMAIL='3exportOptInEmailsToBrowser@test.com'
> > > > > > > OPTIN='1'/>
> > > > > > >
> > > > > > > </dataset>
> > > > > > >
> > > > > > > This works well for Unit style tests with WebTest..  I only
> > > > wish that
> > > > > I
> > > > > > > could get my results into a format that JUnit could use.  Or
> > > > > > some sort of
> > > > > > > wrapper JUnit testcase that would call Ant and put the results
> > > > > > out in a more
> > > > > > > Junit friendly format..
> > > > > > >
> > > > > > > Eric
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Torben Tretau [mailto:wt@tretau.net]
> > > > > > > Sent: Monday, October 21, 2002 7:47 AM
> > > > > > > To: webtest@gate.canoo.com
> > > > > > > Subject: [Webtest] Testdata
> > > > > > >
> > > > > > >
> > > > > > > Hi,
> > > > > > >
> > > > > > > got time to think about some features at the weekend.
> > > > > > > I thought about how to use testdata and got into some
> > > > > > > thoughts about to place the data into a database - and
> > > > > > > link this data to my xml-description, clearlier: my settings
> > > > > > > of input fields.. Could be an interesting feature in my
> > > > > > > opinion..
> > > > > > >
> > > > > > > Now my question: how does other people think about that,
> > > > > > > how do they use testdata and do they think that the above
> > > > > > > feature is useful?
> > > > > > >
> > > > > > > RFC.. bye,
> > > > > > > Torben
> > > > > > > _______________________________________________
> > > > > > > WebTest mailing list
> > > > > > > WebTest@lists.canoo.com
> > > > > > > http://lists.canoo.com/mailman/listinfo/webtest
> > > > > > >
> > > > > > >
> > > > > > _______________________________________________
> > > > > > WebTest mailing list
> > > > > > WebTest@lists.canoo.com
> > > > > > http://lists.canoo.com/mailman/listinfo/webtest
> > > > > >
> > > > >
> > > > > _______________________________________________
> > > > > WebTest mailing list
> > > > > WebTest@lists.canoo.com
> > > > > http://lists.canoo.com/mailman/listinfo/webtest
> > > > >
> > > > >
> > > > _______________________________________________
> > > > WebTest mailing list
> > > > WebTest@lists.canoo.com
> > > > http://lists.canoo.com/mailman/listinfo/webtest
> > > >
> > >
> > > _______________________________________________
> > > WebTest mailing list
> > > WebTest@lists.canoo.com
> > > http://lists.canoo.com/mailman/listinfo/webtest
> > >
> > >
> > _______________________________________________
> > WebTest mailing list
> > WebTest@lists.canoo.com
> > http://lists.canoo.com/mailman/listinfo/webtest
> >
> 
> _______________________________________________
> WebTest mailing list
> WebTest@lists.canoo.com
> http://lists.canoo.com/mailman/listinfo/webtest
> 
>