[Webtest] Testdata

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