[Webtest] Dynamic field naming

Dierk Konig Dierk.Koenig@canoo.com
Wed, 20 Mar 2002 21:15:25 +0100


Hiall,

I would like to add that this feature typically indicates that one
tries to use functional tests (WebTests) for logic.

It may seem strange but this is not what functional tests are
suppose to do. Logic is to be handled by Unit Tests.
(cf http://www.junit.org)

Functional tests assert that the units that make up the logic
are assembled correctly. With DB that typically means that one
well-known call is enough to test through the web-interface.

cheers
Dierk


> -----Original Message-----
> From: webtest-admin@lists.canoo.com
> [mailto:webtest-admin@lists.canoo.com]On Behalf Of Carsten Seibert
> Sent: Mittwoch, 20. Marz 2002 14:34
> To: Webtest mailing list (E-mail)
> Subject: RE: [Webtest] Dynamic field naming
>
>
> Hi Ben,
>
> we are thinking about such a feature as well. Our "business case" shows a
> system-generated  transaction id somewhere on a page. It must be verified
> that the same id appears later in a summary.
>
> A solution could be an extension to the existing verifyXXX statement like:
>
> 	<verifytext
> 		text="Transaction ID: .* <BR/>"
> 		regex="true"
> 		storevalue="transactionID" />
>
> Using the previously stored value would look like using the
> counter variable
> in a repeat statement:
>
> 	<verifytext
> 		text="Transaction ID: #{transactionID}" />
>
> The storevalue attribute is only valid if a regular expression is used.
> Another option would be a new statement that is explicitly used to extract
> text using a regular expression:
>
> 	<extracttext
> 		expression="Transaction ID: .* <BR/>"
> 		storevalue="transactionID" />
>
>
> Any opinions on these two variants?
>
> Regarding interfacing with a SQL database and obtaining properties values
> for tests from there, one could use the ant sql task to execute a
> statement
> like:
>
> 	...
> 	<property name="propertyFilename"
> value="Reports/dbValue.properties"/>
>
> 	<target name="createPropertyFile">
> 		<sql
> 		    driver="${frontnet.jdbc.driver}"
> 		    url="${frontnet.jdbc.url}"
> 		    userid="${frontnet.jdbc.user}"
> 		    password="${frontnet.jdbc.password}"
> 		    src="prepareDB/prepProperty.sql"
> 		    print="true"
> 		    output="${propertyFilename}"
> 		    showheaders="false">
> 			<classpath>
> 				<pathelement
> location="c:/jdk1.2.2/jre/lib/ext/classes12.zip"/>
> 			</classpath>
> 		</sql>
> 	</target>
>
> 	<target name="checkProperty" depends="createPropertyFile">
> 		<property file="${propertyFilename}" />
> 		<echo message="My property created from db is:
> ${dbValue}" />
> 	</target>
> 	...
>
> The external SQL statement in prepareDB/prepProperty.sql looks like:
>
> 	select 'dbValue=' || count(*) from partner;
>
> The property file resulting as output from the above SQL tasks looks like:
>
> 	dbValue=2342
>
> and can be loaded and used in the ant tasks as demonstrated above.
>
> As to the FFO sample in the distribution: It seems that the "missing"
> properties are loaded in an "outer" context, i.e. from an ant task that
> invokes the scripts in question. We'll have a look into this in order to
> make the samples consistent.
>
> Ciao,
> Carsten
>
> Carsten Seibert
> seiberTEC GmbH Switzerland
>
> > -----Original Message-----
> > From: webtest-admin@gate.canoo.com
> > [mailto:webtest-admin@gate.canoo.com]On Behalf Of Ben Cox
> > Sent: Dienstag, 19. Marz 2002 20:43
> > To: webtest@gate.canoo.com
> > Subject: [Webtest] Dynamic field naming
> >
> >
> >    I am trying to use webtest, and, while I think it's great, I am
> > finding a little difficult to use in practice.  One thing that would
> > really help is the ability to use the text that matches a
> > regex in one
> > of the verifyXXX tags later in the build file somehow, so that, for
> > example, the names of form fields and the values they hold could be
> > detemined dynamically in the later invocations of setXXX tags.
> >    In particular, I am trying to write tests (better late than never)
> > for a webapp that uses object ids in many of its form fields,
> > and those
> > ids are determined by an autoincrement in MySQL.  It seems that MySQL
> > won't roll back to using id number 1 after deleting all of
> > the entries
> > if I am using the same JVM and connection pool to insert the new one
> > (which the webapp is unless I take it down), so the numbers in the
> > names/values of form fields that I need to click end up different in
> > subsequent runs of the tests.  Though the webapp will frequently be
> > taken down between test runs once the tests are written, this is
> > particularly unwieldy while trying to debug the tests
> > themselves, rather
> > than the code they're testing, because the webapp doesn't
> > have to come
> > down in between each run and change of the test.
> >    This brings me to a question about the "ffo" sample in the WebTest
> > CVS distribution.  It seems that most of the invocations of
> > <clickbutton>, <setinputfield>, etc.  use properties in their value
> > attributes that often look something like ${z00__wb} or
> > ${draft_contract}.  I can't find anywhere that these are
> > initialized in
> > the sample buildfiles or props files, so I was wondering how
> > and where
> > these properties are being set?  Is there another framework or tool
> > (perhaps buillding on ant?) that this sample project uses?
> > This _looks_
> > like it addresses the problem I'm facing, but I really can't
> > tell what
> > it's doing!
> >    If anyone has some idea of what's going on in there, or a good
> > implementation of this concept, would you be so kind as to
> > shed a little
> > light over here?
> >    Thanks in advance,
> >
> >       Ben
> >
> > _______________________________________________
> > 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
>