James,

I was initially thinking of something like this for loading, removing and
comparing test data for functional and possibly unit testing:

Priming a test database with data before test execution:
<dbunit:insertDataset  file="dataset.xml" datasource="ds" />

Extract data from an existing database to use as test data or expected
results
<dbunit:createDataset  file="dataset.xml" tables="TABLE1, TABLE2"
datasource="ds" />

or from a query:
<dbunit:createDataset  file="dataset.xml" sql="select * from company"
datasource="ds" />

Compare an expected result data set with the contents of the test database
<dbunit:assertExpected  file="expected_dataset.xml"  sql="select..."
datasource="ds" />

or may be compare a set of tables against a data set
<dbunit:assertExpected  file="expected_dataset.xml" tables="TABLE1, TABLE2"
datasource="ds" />

remove test data mentioned within the data set
<dbunit:deleteDataset file="dataset.xml" datasource="ds" />

May be there's also a way to declare the XML data sets within a Jelly script
itself and then refer to them directly rather than a file - may be useful
for smaller data or result sets.  Possibly:

<dbunit:insertDataset datasource="ds">
  <dataset>
     <table name="TEST_TABLE">
       <column="COL1" />
       ...
    <table/>
  </dataset>
</dbunit:insertDataset>

Although useful this syntax seems more verbose especially for describing
test data.  DBUnit has specified a new XML schema which they call
FlatXMLDataSet - elements are collapsed into columns making the XML somewhat
less verbose.  Still for data driven test cases I would expect most people
to extract the data and then refer to the file for verification.

There's a fair degree of overlap here with the SQL tags and some overlap
with Jelly unit.  Ideally the library would sit above the two other common
taglibs and combine them to generate new behaviour.  Does it make sense to
create another tag library to wrap DBUnit or would the functionality be
better placed within the SQL tags ?



Darren

-----Original Message-----
From: James Strachan [mailto:[EMAIL PROTECTED]]
Sent: 01 October 2002 08:20
To: Jakarta Commons Users List
Subject: Re: Jelly and Ant Exec output property


Hi Darren

From: "Darren Syzling" <[EMAIL PROTECTED]>
> Hi James,
>
> No problem - understand you've been busy, thanks for the reply.
>
> I tried the recent b3 release and this seemed to clear some of my other
> problems.  Using the Jelly task from Ant still seems to cause problems.
For
> the time being I'm using a workaround - using the Ant Java task and
forking
> a separate process, then load my Ant defined properties from the Jelly
> script.  At least I've now got a working prototype for a set of functional
> test scripts for our application.
>
> One piece of functionality I think I'm missing from the current set of tag
> libraries is a way of comparing an expected result set against the result
of
> a query against the database.  I'd like a test analyst to be able to
> construct (or extract from an existing database) the expected result set
in
> XML.  I'm thinking of wrapping some of the behaviour in DBUnit to achieve
> this.  Not sure if this more widely applicable to the community ?

Sounds groovy.

What kind of XML markup would you like to use?

Whenever I find myself chatting with someone about Jelly I try and
emphasise, what would you like the XML to look like, rather than focus on
the current XML languages that Jelly supports. Basically because with Jelly
we can pretty much implement most declarative & procedural XML languages.
Obviously its nice to reuse some of the exisitng XML languages (tag
libraries) if possible.

e.g. right now you could (say) create a bean, configure it then call some
method and assert that its equal to some value in an SQL result set.

<!-- lets do a JellyUnit test case -->
<test:case name="testTax">

    <!-- lets make a bean and set its properties -->
    <j:useBean var="bean" class="com.acme.Foo" name="James" location="uk"/>

    <!-- lets do some SQL -->
    <sql:query var="results">select * from results where name =
'James'</sql:query>

    <!-- assertions -->
    <test:assertEquals expected="${results.rows[0].amount}"
actual="${bean.calculateTax()}"/>
</test:case>


Would this kind of thing be useful or were you thinking of something else?


> I'd like to go back and investigate the source of the problems with the
> Jelly task (+Ant/Jelly interactions) - hopefully I can find some time this
> week and I'll report back.  Anything I can do to help...

Great, thanks Darren

James
-------
http://radio.weblogs.com/0112098/

__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com

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


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

Reply via email to