[Webtest] Dynamic field naming

Dierk Konig webtest@lists.canoo.com
Fri, 22 Mar 2002 09:52:58 +0100

Hi Ben,

>    Actually, I'm simply trying to do a very simple end to end as if I
> was a user.  A user logs in, goes to the empty quotes page, creates a
> new quote, submits it, goes back to the quotes page,  ensures it's now
> got a table of quotes, and deletes the new one.  Not too complicated,
> and, since the customer wouldn't accept that the site works unless a
> user can do this, this seems like functional testing to me :-)

I fully agree.

It's a static sequence of steps, and it should be possible to do this
with webtest.

Where steps the autoincrement in, from the user perspective?
I haven't got that.

Is it the names of the input paramaters? The Values?
I don't think so.

How does it work if you check you webapp manually?

> ..
>    So, without stopping and starting the server to ensure that MySQL is
> being accessed by different connections, I can't know for sure what the
> ID of the newly inserted quote is.

Isn't it enough to check for the number of quotes in the page?
Can you possibly check it with a regex?

When you really need to reset the DB, why not doing it via an
Administration Servlet that you call via WebTest?

(We sometimes even create users via WebTests, let them do some
trades and remove them at the end of the test. This, to ensure a
"well-known" test environment. )

> Seems like in the webapp
> environment, with connection pooling on the server and whatnot, it's
> difficult to ensure that the "known database call" is really known!  If
> I was writing the tests before the app, it might be easy to work around,
> but I'm not :-(

Well, for the functional testing one often needs some sophisticated
setup like test- and integration DB's that can be recovered including
the test data. Starting from scratch is the only way to ensure "well-known"
calls in that case.

That is why functional testing is so much harder than unit testing where
you just fake the DB.

>    I couldn't find anything on the JUnit site specifically about
> functional testing, really, but I've read my share of XP literature and,
> though it's fuzzy, the impression I got as to what functional
> (acceptance) tests were supposed to do is basically that which I'm doing
> here.

Yes, your'e on the right track (or I am wrong as well :-)).

>  I thought I was on the right track!  Will someone please point me
> to a good explanation of where the line gets drawn?  Or, explain where I
> should stop in my simple end-to-end in order for it to qualify as
> "functional testing"?

I'm not sure where your testing effort is really targeted at.
What I ask myself in such a case is:
- what _did_ break lately?
  (DB-call of quote insertion, DB-call of qoute deletion,
   HTML rendering of quote, quote insertion into user session,..)
- what is the easiest way to test this?
  (Unit test for DB-statements, Unit tests for proper HTML,
   Unit tests for user-session handling, ...)

>    By the way, has anyone investigated the use of this sort of
> Ant-based, XML-specified architecture for doing unit testing?  If
> WebTest were to expose more of the functionality in the HttpUnit API, it
> might be able to handle both types of testing!  This would probably
> require a more heirarchical schema for the task definition, however.

There is a tool from some guys in Australia or New Zealand that I saw a
presentation of at OOPSLA 99. It captures Unit Tests in XML, executes them
and reports execution. (it is called JUnitX or so)

It is my considered opinion that Unit tests need to be expressed in your
programming language and that they need to go with your code without
any barrier. I need to switch smoothly between Unit Tests and production
code minute-by-minute. My Unit Tests capture the design, and the api, both
in syntax and semantic. To do this in my programming language comes most
natural to me.

Why then putting the functional tests in XML/ANT?
They belong to the customer. He needs to understand and maintain it.


>    Thanks for the advice,
>      Ben
> Dierk Konig wrote:
> > 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
> >>
> >>
> >
> > _______________________________________________
> > WebTest mailing list
> > WebTest@lists.canoo.com
> > http://lists.canoo.com/mailman/listinfo/webtest
> >
> >
> >