Consult if dbunit is proper for our project

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Consult if dbunit is proper for our project

kittyfxm

   Dear dbunit user,
   Our project is an application server deployed in weblogic, use EJB technology.

   Here is our Unit test structure, we insert the basic test data to db in setUpBeforeClass () method for each test suite, tearDownAfterClas() method to delete the test data inserted.

   For some test cases, they required special test data, because we can not invoke API of source code directly to insert/Query/Update test data, so we define several methods which invoke JDBC directly to insert test data. And the db structure is a little bit complicated and we have to create one method to import test data for each independent db table. For the moment, we can realize the goal we wanted with this way. But for maintenance it is difficult, each developer here complain this, when debug, it is difficult to find the reason.

   I find the dbunit tool from the web, I browse the guide a little, it can help a lot for db application. I want to make sure if it fits our needs. Because for each test of test suite, we have to update/insert/query different test data, it is not enough only depends setup() method.

For one test suite, if I use dbunit to import test data, should I need one data file for each test if it requires special test data? Maybe there is other good solution to meet this, Could you give some advice for this topic? Thanks.

 

Best Regards,

Kitty




没有广告的终身免费邮箱,www.yeah.net



没有广告的终身免费邮箱,www.yeah.net



没有广告的终身免费邮箱,www.yeah.net

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
dbunit-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/dbunit-user
Reply | Threaded
Open this post in threaded view
|

Re: Consult if dbunit is proper for our project

Paolo DiCanio
Hi Kitty,

You can either have a different dataset for each class, or use the same dataset for several (or even all) classes. It's probably also possible to use a different dataset for different test methods within the same class, but that would require a little more work. In my opinion the best way to work with test data is

- start transaction
- load DbUnite dataset
- run test (insert, update, delete, etc.)
- rollback transaction

Because the transaction is rolled back even if an exception occurs, you are guaranteed that the end state of the DB will be the same as the start state. Of course, you could try to programatically delete the data instead, but this will require a lot more code (than rolling back a transaction), without providing any obvious benefits.

Cheers,
Don


From: kittyfxm <[hidden email]>
To: dbunit-user <[hidden email]>
Sent: Tuesday, 25 August, 2009 5:47:31
Subject: [dbunit-user] Consult if dbunit is proper for our project

   Dear dbunit user,
   Our project is an application server deployed in weblogic, use EJB technology.

   Here is our Unit test structure, we insert the basic test data to db in setUpBeforeClass () method for each test suite, tearDownAfterClas() method to delete the test data inserted.

   For some test cases, they required special test data, because we can not invoke API of source code directly to insert/Query/Update test data, so we define several methods which invoke JDBC directly to insert test data. And the db structure is a little bit complicated and we have to create one method to import test data for each independent db table. For the moment, we can realize the goal we wanted with this way. But for maintenance it is difficult, each developer here complain this, when debug, it is difficult to find the reason.

   I find the dbunit tool from the web, I browse the guide a little, it can help a lot for db application. I want to make sure if it fits our needs. Because for each test of test suite, we have to update/insert/query different test data, it is not enough only depends setup() method.

For one test suite, if I use dbunit to import test data, should I need one data file for each test if it requires special test data? Maybe there is other good solution to meet this, Could you give some advice for this topic? Thanks.

 

Best Regards,

Kitty




没有广告的终身免费邮箱,www.yeah.net



没有广告的终身免费邮箱,www.yeah.net



没有广告的终身免费邮箱,www.yeah.net


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
dbunit-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/dbunit-user
Reply | Threaded
Open this post in threaded view
|

Re: Consult if dbunit is proper for our project

John Hurst-2
Kitty,

We've used DbUnit for some years, and have settled into a pattern that is very suitable for the situation you describe.

We have a DbUnitTestCase base class for DbUnit tests. This class provides common features for all the database tests in the project:
  - Inject the DataSource for the database
  - Load common reference data once per test suite run
  - Common utility methods to use DbUnit to load test-specific data

Our DbUnitTestCase does not extend a DbUnit base class, but rather delegates work to DbUnit. Please do not assume that the only way to use DbUnit is by extending DBTestCase. It's often better not to, if you want more control over the test data lifecycle.

We have common data for all tests (lookup tables) that don't change during the running of tests. We put those data in a single FlatXmlDataSet file, say "common.xml", and have our DbUnitTestCase load that once per suite (controlled by a static boolean field).

Test-specific data are loaded in each test method. Because these data vary per test, I've found it's better to locate them closer to the test code. So we don't put them in XML files, but rather inline as CSV strings in the test code.

I have mixed feelings about the "transaction rollback in tearDown()" pattern described. It certainly makes your tests run faster, but it can add complications for some kinds of database testing. The main drawbacks are:
  - You lose some test isolation. All tests assume the same starting point.
  - You can't see what's in the database when something goes wrong.
  - You have to be very careful not to inadvertently commit during your test.
  - You cannot easily mix in code that does need to commit, e.g. some stored procedures, code with DDL (such as DROP/recreate a sequence).

These issues can all be worked around, but for our work we've found that not using rollback was more robust and less troublesome.

I described how to use inline data for tests using Groovy/Grails in my blog recently: http://skepticalhumorist.blogspot.com/2009/07/inline-data-for-dbunit-tests-in-grails.html. I also wrote Chapter 14 on DbUnit for the Java Power Tools book (O'Reilly 2008). This describes how to use inline test data with DbUnit in Java, and contains tips about organizing test data and managing database tests. I really need to get some of that stuff out in the wiki or something. (But if you can get the book, it's very useful! ;-)

John Hurst
Wellington, New Zealand

On Wed, Aug 26, 2009 at 12:25 AM, Donal Murtagh <[hidden email]> wrote:
Hi Kitty,

You can either have a different dataset for each class, or use the same dataset for several (or even all) classes. It's probably also possible to use a different dataset for different test methods within the same class, but that would require a little more work. In my opinion the best way to work with test data is

- start transaction
- load DbUnite dataset
- run test (insert, update, delete, etc.)
- rollback transaction

Because the transaction is rolled back even if an exception occurs, you are guaranteed that the end state of the DB will be the same as the start state. Of course, you could try to programatically delete the data instead, but this will require a lot more code (than rolling back a transaction), without providing any obvious benefits.

Cheers,
Don


From: kittyfxm <[hidden email]>
To: dbunit-user <[hidden email]>
Sent: Tuesday, 25 August, 2009 5:47:31
Subject: [dbunit-user] Consult if dbunit is proper for our project

   Dear dbunit user,
   Our project is an application server deployed in weblogic, use EJB technology.

   Here is our Unit test structure, we insert the basic test data to db in setUpBeforeClass () method for each test suite, tearDownAfterClas() method to delete the test data inserted.

   For some test cases, they required special test data, because we can not invoke API of source code directly to insert/Query/Update test data, so we define several methods which invoke JDBC directly to insert test data. And the db structure is a little bit complicated and we have to create one method to import test data for each independent db table. For the moment, we can realize the goal we wanted with this way. But for maintenance it is difficult, each developer here complain this, when debug, it is difficult to find the reason.

   I find the dbunit tool from the web, I browse the guide a little, it can help a lot for db application. I want to make sure if it fits our needs. Because for each test of test suite, we have to update/insert/query different test data, it is not enough only depends setup() method.

For one test suite, if I use dbunit to import test data, should I need one data file for each test if it requires special test data? Maybe there is other good solution to meet this, Could you give some advice for this topic? Thanks.

 

Best Regards,

Kitty




没有广告的终身免费邮箱,www.yeah.net



没有广告的终身免费邮箱,www.yeah.net



没有广告的终身免费邮箱,www.yeah.net


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
dbunit-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/dbunit-user




--
COH: Level 10 US

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
dbunit-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/dbunit-user
Reply | Threaded
Open this post in threaded view
|

Re: Consult if dbunit is proper for our project

kittyfxm
Thanks for your information.
Unfortunately, I can not open the blog address you mentioned.
If I have some problem during using dbunit, maybe i will bother you again. Hope you do not mind. thanks.
Best Regards,
Kitty
在2009-08-25 21:40:10,"John Hurst" <[hidden email]> 写道:
Kitty,

We've used DbUnit for some years, and have settled into a pattern that is very suitable for the situation you describe.

We have a DbUnitTestCase base class for DbUnit tests. This class provides common features for all the database tests in the project:
  - Inject the DataSource for the database
  - Load common reference data once per test suite run
  - Common utility methods to use DbUnit to load test-specific data

Our DbUnitTestCase does not extend a DbUnit base class, but rather delegates work to DbUnit. Please do not assume that the only way to use DbUnit is by extending DBTestCase. It's often better not to, if you want more control over the test data lifecycle.

We have common data for all tests (lookup tables) that don't change during the running of tests. We put those data in a single FlatXmlDataSet file, say "common.xml", and have our DbUnitTestCase load that once per suite (controlled by a static boolean field).

Test-specific data are loaded in each test method. Because these data vary per test, I've found it's better to locate them closer to the test code. So we don't put them in XML files, but rather inline as CSV strings in the test code.

I have mixed feelings about the "transaction rollback in tearDown()" pattern described. It certainly makes your tests run faster, but it can add complications for some kinds of database testing. The main drawbacks are:
  - You lose some test isolation. All tests assume the same starting point.
  - You can't see what's in the database when something goes wrong.
  - You have to be very careful not to inadvertently commit during your test.
  - You cannot easily mix in code that does need to commit, e.g. some stored procedures, code with DDL (such as DROP/recreate a sequence).

These issues can all be worked around, but for our work we've found that not using rollback was more robust and less troublesome.

I described how to use inline data for tests using Groovy/Grails in my blog recently: http://skepticalhumorist.blogspot.com/2009/07/inline-data-for-dbunit-tests-in-grails.html. I also wrote Chapter 14 on DbUnit for the Java Power Tools book (O'Reilly 2008). This describes how to use inline test data with DbUnit in Java, and contains tips about organizing test data and managing database tests. I really need to get some of that stuff out in the wiki or something. (But if you can get the book, it's very useful! ;-)

John Hurst
Wellington, New Zealand

On Wed, Aug 26, 2009 at 12:25 AM, Donal Murtagh <[hidden email]> wrote:
Hi Kitty,

You can either have a different dataset for each class, or use the same dataset for several (or even all) classes. It's probably also possible to use a different dataset for different test methods within the same class, but that would require a little more work. In my opinion the best way to work with test data is

- start transaction
- load DbUnite dataset
- run test (insert, update, delete, etc.)
- rollback transaction

Because the transaction is rolled back even if an exception occurs, you are guaranteed that the end state of the DB will be the same as the start state. Of course, you could try to programatically delete the data instead, but this will require a lot more code (than rolling back a transaction), without providing any obvious benefits.

Cheers,
Don


From: kittyfxm <[hidden email]>
To: dbunit-user <[hidden email]>
Sent: Tuesday, 25 August, 2009 5:47:31
Subject: [dbunit-user] Consult if dbunit is proper for our project

   Dear dbunit user,
   Our project is an application server deployed in weblogic, use EJB technology.

   Here is our Unit test structure, we insert the basic test data to db in setUpBeforeClass () method for each test suite, tearDownAfterClas() method to delete the test data inserted.

   For some test cases, they required special test data, because we can not invoke API of source code directly to insert/Query/Update test data, so we define several methods which invoke JDBC directly to insert test data. And the db structure is a little bit complicated and we have to create one method to import test data for each independent db table. For the moment, we can realize the goal we wanted with this way. But for maintenance it is difficult, each developer here complain this, when debug, it is difficult to find the reason.

   I find the dbunit tool from the web, I browse the guide a little, it can help a lot for db application. I want to make sure if it fits our needs. Because for each test of test suite, we have to update/insert/query different test data, it is not enough only depends setup() method.

For one test suite, if I use dbunit to import test data, should I need one data file for each test if it requires special test data? Maybe there is other good solution to meet this, Could you give some advice for this topic? Thanks.

 

Best Regards,

Kitty




没有广告的终身免费邮箱,www.yeah.net



没有广告的终身免费邮箱,www.yeah.net



没有广告的终身免费邮箱,www.yeah.net


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
dbunit-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/dbunit-user




--
COH: Level 10 US



没有广告的终身免费邮箱,www.yeah.net

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
dbunit-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/dbunit-user
Reply | Threaded
Open this post in threaded view
|

Ask for help about inline data set

kittyfxm
In reply to this post by John Hurst-2
Hello John,
 I have a question need your help.
 I put test data in the test code, just like the inline data set you mentioned.
 First Question:I want to know how to hanle this kind of data: sysdate(The date when insert data to db) and the sequence data (we define sequence to generate ID for some tables)for one table.
 Second Question: When insert test data for several tables, the output of the first data is the input of the rest of table.How to handle this kind of case.
Thanks for your help.
 
Best Regards,
Kitty



没有广告的终身免费邮箱,www.yeah.net

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
dbunit-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/dbunit-user