[Webtest] Testdata

Dierk Koenig webtest@lists.canoo.com
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
>