Actually,

I should back pedal and say that I didn't select it over a Junit testing
framework, instead it is yet another testing tool (Y.A.T.T!).

I use JUnit tests for all my little bits of code, like FilenameFilters etc..
Things that basically don't need a database.  I use Cactus (and DBUnit to
set up the db!) for all my repeatable things like services and large actions
in Turbine.  Basically anything that neeeds Turbine or a database to run.

However, what I find is that those test individual components well, but
dont't test a whole series of pages from the perspective of a user.  Yes,
page 1 may work according to Cactus test.  Yes page 2 may work according to
Cactus test.  But does clicking from the homepage, logging in, and then
going to page 1 and then page 2 work?  That is a very complex/ maybe
undoable Cactus test.  But from Webtest, it is very easy. 

WebTest makes it very easy to write complex testcases quickly.  It also does
well to test a web page in a more unit style test.  Here (sorry I was
testing an ASP app ;-) ) is an example of using DBUnit to reset my database,
use webtest to test the page and evaluate the results:

<target name="redirectionURLEndingInSlash">
  <dbunit 
    driver="${sql.jdbcdriver}"          
    url="${sql.url}"          
    userid="${sql.username}"          
    password="${sql.password}">    
        <operation type="MSSQL_REFRESH"
src="data/redirectionURLEndingInSlash.xml" format="flat"/>
  </dbunit>


  <testSpec name="redirectionURLEndingInSlash">
    &sharedConfiguration;
    <steps>
      <invoke stepid="redirection url ending in a slash"
              url="${r.page}?r=1/"
        save="redirectionURLEndingInSlash"/>
      <verifytext stepid="Make sure we are redirected to the upstate info
page"
        text="Upstate develops the most innovative products"/> 
        
    </steps>
  </testSpec>                             
</target>

This is a very simple example, where we set up the data in the database
required for the next step to work using dbunit.  Then in the next step we
invoke a URL, and then verify the elements on it.  

Obviously this is a very simple one page example, that could also be done
relatively easily as a Cactus test.  But string a bunch of pages together
and you get the idea!

Eric Pugh

-----Original Message-----
From: Scott Eade [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, December 11, 2002 7:08 PM
To: turbine-user
Subject: Re: Turbine + Tomcat Peformance


> From: [EMAIL PROTECTED]
> 
> WebTest is my favorite little user acceptance tool.  It is ant based, and
> allows you to script calls through a webapp to test your webapp
> functionality.  webtest.canoo.com is the url.  There is also a maven
plugin
> for it.  it gives you a great "web browser" perspective on testing your
> apps.

Eric,

Would you care to comment as to why you selected WebTest over say one of the
JUnit based testing frameworks (e.g. Cactus).

Cheers,

Scott
-- 
Scott Eade
Backstage Technologies Pty. Ltd.
http://www.backstagetech.com.au



--
To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>

Reply via email to