John,
Okay, that's a good distinction. You're not looking for regression or
system wide tests, which generally take enough time to run that
building a test database (about 3 minutes on Derby on my laptop) is
not a significant amount of time.
For quick tests like this I'd recommend creating test services that
do the build up, code run, and results test all at once and then just
roll back the transaction to do the cleanup. This tends to work
fairly well and leverages existing transaction functionality that is
pretty solid and does the "undo" easily. This is a lot easier than
trying to save the state of the db and restoring it in the tear down.
Of course, if you're not worried about developer efficiency, then
code away and have a good time... ;)
-David
On Oct 24, 2006, at 6:07 PM, John Martin wrote:
Hi David,
I think that the "throw away" database idea is probably out of the
question for my needs. I code in an iterative process and need to
repeat the tests through the coding/debugging cycle. When the code is
complete, so is the test suite for that service or set of services
which is then available for regression testing in the system.
During the development cycle I could run the tests 10-30 or more times
depending on the complexity. If I understand your solution, one would
need to repopulate the database after each iteration which would be
very time consuming. In addition, I could see issues with the XML
entity comparision with createXXX and lastUpdatedXXX datetime columns
as well as the autoincrement id columns.
What I am really looking for is the junit functionality where the test
suite has a build up and tear down section that is called before/after
the tests. If this build up / tear down could be driven with XML,
that would be best.
It seems that the dbUnit project is more in line with what I am
looking for. I'm going to explore this option and will colaborate
with Tim on this.
Thanks,
John
On 10/24/06, David E Jones <[EMAIL PROTECTED]> wrote:
John,
Part of the test plan for OFBiz (that has been around for well over a
year has not seen much attention) is to be able to easily to data
level testing. We plan to use the OOTB demo and seed data as the
initial database state, and then after tests are done the test
database would simply be thrown away (avoiding the need to "undo" all
test changes).
To validate results on the data level there is an existing feature in
the simple-method that we plan to make easier to use in the test
config XML files. What it does is read an entity engine XML file
(which can exported from WebTools, or created manually) and validate
it against the database by asserting that each element in the XML
file matches a database record. It reports records that are missing
and all fields that are different for existing records.
Is that more or less what you are looking for? The intent with these
is to be intermixed with UI level tests and test services and such to
provide testing facilities for the various architectural layers in
OFBiz.
-David
On Oct 24, 2006, at 6:54 AM, John Martin wrote:
> Grinder does look really interesting and appears to me to be geared
> more for testing the application for a UI and performance
perspective.
>
> What I am really after is something that is more database
oriented to
> allow a test suite to initialize data appropriately, run the
test, and
> then clean out the test data. I'm writing new services to
> insert/update data and want to have a simple way of building
tests to
> make sure that my code is working correctly.
>
> Currently, I write a test script that invokes the service and I
> inspect the results and walk through the code in the debugger. I
> agree with Brett that "creating data driven tests were still
difficult
> to create and maintain." There's got to be an easier way...
>
> Brett - I would be interested in the JXUnit integration with ofBiz
> since that appears to be inline with what I'm trying to do. Can
point
> me to where I can get what I would need to use it?
>
> Thanks,
>
> John
