---------- Forwarded message ---------- From: javawug group <[EMAIL PROTECTED]> Date: Oct 30, 2007 7:58 AM Subject: 4 new messages in 2 topics - digest To: javawug digest subscribers <[EMAIL PROTECTED]>
JAVAWUG http://groups.google.co.uk/group/javawug?hl=en [EMAIL PROTECTED] Today's topics: * DBunit for testing & inserting data rather than use dao.create() - 2 messages, 2 authors http://groups.google.co.uk/group/javawug/browse_thread/thread/aaef6bc006610731?hl=en * bof 31 registrations - 2 messages, 2 authors http://groups.google.co.uk/group/javawug/browse_thread/thread/324a8fc7ec5b0fe2?hl=en ============================================================================== TOPIC: DBunit for testing & inserting data rather than use dao.create() http://groups.google.co.uk/group/javawug/browse_thread/thread/aaef6bc006610731?hl=en ============================================================================== == 1 of 2 == Date: Mon, Oct 29 2007 4:31 am From: Phil Zoio I'd agree that you are generally better off using DbUnit to populate your data sets, unless your application is very small or has very small set up data setup requirements. DbUnit is more flexible, as you can ingest any data you want/need at test time. Achieving the same setup through code can be tedious. On the other hand, using the API itself does give you the benefit that all of the data you insert is internally consistent, that is, obeys the validation rules that you may have specified both through the database as well as through Hibernate validation/constraints. However, the reality is that some data is probably going to need to be ingested via scripts, and DbUnit is a pretty good way of doing this. One approach which I find works quite well is: 1) in the setUp() method for any test which uses the database, run the "delete from TABLE_X" sql for any table which is in the database. You can set up a utility method for this and run it using Spring JDBC. I find that DbUnit doesn't work so well for this purpose, because DbUnit will only delete the tables defined in the current data set. 2) also in the setUp() method, use DbUnit to insert data as Adam suggests. Of course, here you may be adding a general set of data and/or data which is specific to the current test 3) run your data dependent tests The Hypersonic in memory database configuration is very easy to set up and get going with, but two downsides using it are: you don't get to see the data, because as soon as your test has finished running and the JVM terminates, your data gone. Secondly, you also need to maintain a "real" configuration (with, say, Oracle or MySQL), which means you need to maintain the infrastructure for switching between your Hypersonic and your real configuration. As a result, I'm tending to bypass the HSQL config these days. Regards, Phil Adam Hardy wrote: >Hi Marco, > >I'm using a combination of DbUnit and hypersonic in-memory db to load up >fresh data into an empty schema for every test. > >It beats any other method I've used hands-down. > >Unless you do this, you have problems with the data in the database >getting hacked about and the tests fail. We ended up continually fixing >data or editing the tests, it's a license to waste time. > >The dbunit xml format for storing data is reasonable enough but changes >to the schema require changes to the dbunit xml - I handled this using a >program that will load up the data into the old schema, execute an sql >script to alter the schema and initialise any new columns etc, and then >export the data back out to xml again. > >It ended up being easier to maintain the data this way than the old way >of going through the unit test code and updating every data-create >method that had broken. > > >Regards >Adam > > > >Marco on 28/10/07 09:38, wrote: > > >>hi all, >> i'd like to promote the use of DbUnit @ work, as our tests are >>currently relying on data being already in the database. >>Additionally , for populating db we are using jdbcTemplate ... or some >>dao.create methods >> >>Argument @work is that, since we are using Hibernate, we should as >>well use each hibernateDao.create method to insert the data in the >>database. >>I personally think that we should not use a method (create()) that we >>are also supposed to test for populating the database, and we should >>use DbUnit instead...... >>but i don't know if mine is a valid argument... >>i was wondering what all of you do for populating testing data.. and >>if you can give me some arguments for using >>dao.create() rather than DbUnit.. >>you can also mail me privately at [EMAIL PROTECTED] >> >> >> > >> > > > == 2 of 2 == Date: Mon, Oct 29 2007 5:15 am From: Adam Hardy DbUnit will ultimately do whatever you say it should do, but as Phil points out, you have to program it that way, which can be a start-up overhead you might not need. I did need it, after working on several projects where the test data was a thorn in the side. Hypersonic or not is not a major issue really. I came a long way with a fairly lightweight dbunit-based set-up which builds my database schema from scratch, and then inserts the dbunit data table by table, in the order that referential integrity constraints require. Keeping that sort of logic and data out of the test code is a major bonus. regards Adam Phil Zoio on 29/10/07 11:31, wrote: > I'd agree that you are generally better off using DbUnit to populate > your data sets, unless your application is very small or has very > small set up data setup requirements. DbUnit is more flexible, as you > can ingest any data you want/need at test time. Achieving the same > setup through code can be tedious. > > On the other hand, using the API itself does give you the benefit that > all of the data you insert is internally consistent, that is, obeys > the validation rules that you may have specified both through the > database as well as through Hibernate validation/constraints. However, > the reality is that some data is probably going to need to be ingested > via scripts, and DbUnit is a pretty good way of doing this. > > One approach which I find works quite well is: > > 1) in the setUp() method for any test which uses the database, run the > "delete from TABLE_X" sql for any table which is in the database. You > can set up a utility method for this and run it using Spring JDBC. I > find that DbUnit doesn't work so well for this purpose, because DbUnit > will only delete the tables defined in the current data set. > > 2) also in the setUp() method, use DbUnit to insert data as Adam > suggests. Of course, here you may be adding a general set of data > and/or data which is specific to the current test > > 3) run your data dependent tests > > The Hypersonic in memory database configuration is very easy to set up > and get going with, but two downsides using it are: you don't get to > see the data, because as soon as your test has finished running and > the JVM terminates, your data gone. Secondly, you also need to > maintain a "real" configuration (with, say, Oracle or MySQL), which > means you need to maintain the infrastructure for switching between > your Hypersonic and your real configuration. As a result, I'm tending > to bypass the HSQL config these days. > > Regards, > Phil > > Adam Hardy wrote: >> Hi Marco, >> >> I'm using a combination of DbUnit and hypersonic in-memory db to load up >> fresh data into an empty schema for every test. >> >> It beats any other method I've used hands-down. >> >> Unless you do this, you have problems with the data in the database >> getting hacked about and the tests fail. We ended up continually fixing >> data or editing the tests, it's a license to waste time. >> >> The dbunit xml format for storing data is reasonable enough but changes >> to the schema require changes to the dbunit xml - I handled this using a >> program that will load up the data into the old schema, execute an sql >> script to alter the schema and initialise any new columns etc, and then >> export the data back out to xml again. >> >> It ended up being easier to maintain the data this way than the old way >> of going through the unit test code and updating every data-create >> method that had broken. >> >> >> Regards >> Adam >> >> >> >> Marco on 28/10/07 09:38, wrote: >> >>> hi all, >>> i'd like to promote the use of DbUnit @ work, as our tests are >>> currently relying on data being already in the database. >>> Additionally , for populating db we are using jdbcTemplate ... or some >>> dao.create methods >>> >>> Argument @work is that, since we are using Hibernate, we should as >>> well use each hibernateDao.create method to insert the data in the >>> database. >>> I personally think that we should not use a method (create()) that we >>> are also supposed to test for populating the database, and we should >>> use DbUnit instead...... >>> but i don't know if mine is a valid argument... >>> i was wondering what all of you do for populating testing data.. and >>> if you can give me some arguments for using >>> dao.create() rather than DbUnit.. >>> you can also mail me privately at [EMAIL PROTECTED] >>> >>> >> >> >> >> > > > > ============================================================================== TOPIC: bof 31 registrations http://groups.google.co.uk/group/javawug/browse_thread/thread/324a8fc7ec5b0fe2?hl=en ============================================================================== == 1 of 2 == Date: Mon, Oct 29 2007 10:13 am From: "Matt Dudbridge" I really want to make this one but I'm a bit poorly at the moment! Will you be video recording this one, Peter? On 10/26/07, Peter Pilgrim <[EMAIL PROTECTED]> wrote: > > > Hi All > > Sorry about this noise! > > If you are going to BOF 31 OpenSymphony Compass, can you respond to > this email please. > > -- > Peter A. Pilgrim > Java EE Software Development / Design / Architecture (``A Sun Java > Champion'') > > :: http://jroller.com/peter_pilgrim :: > :: http://jroller.com/javawug :: > :: https://java-champions.dev.java.net/ > :: http://www.linkedin.com/in/peterpilgrim2000 > :: http://www.facebook.com/profile.php?id=570597454 > :: http://twitter.com/peter_pilgrim > > > > -- _______________________ Matt Dudbridge, Software Development Team Leader [EMAIL PROTECTED] direct : +44 (0) 020 7680 7835 zoomf.com , the future of UK Property Search This email and any attachments are Arclight Media Technology Limited confidential for the recipient(s) and must not be viewed or used by any other persons. Arclight Media Technology Limited Registered in England at 1 Alie Street London E1 8DE Number 05565202 == 2 of 2 == Date: Mon, Oct 29 2007 12:07 pm From: "Peter Pilgrim" On 29/10/2007, Matt Dudbridge <[EMAIL PROTECTED]> wrote: > I really want to make this one but I'm a bit poorly at the moment! > Hi Matt We are sorry that you are feeling unwell and hope that you get better soon. > Will you be video recording this one, Peter? Yes I will bring the camcorder tomorrow evening. > > On 10/26/07, Peter Pilgrim <[EMAIL PROTECTED]> wrote: > > > > Hi All > > > > Sorry about this noise! > > > > If you are going to BOF 31 OpenSymphony Compass, can you respond to > > this email please. > > ==////== -- Peter A. Pilgrim Java EE Software Development / Design / Architecture (``A Sun Java Champion'') :: http://jroller.com/peter_pilgrim :: :: http://jroller.com/javawug :: :: https://java-champions.dev.java.net/ :: http://www.linkedin.com/in/peterpilgrim2000 :: http://www.facebook.com/profile.php?id=570597454 :: http://twitter.com/peter_pilgrim ============================================================================== You received this message because you are subscribed to the Google Groups "JAVAWUG" group. To post to this group, send email to [EMAIL PROTECTED] or visit http://groups.google.co.uk/group/javawug?hl=en To unsubscribe from this group, send email to [EMAIL PROTECTED] To change the way you get mail from this group, visit: http://groups.google.co.uk/group/javawug/subscribe?hl=en To report abuse, send email explaining the problem to [EMAIL PROTECTED] ============================================================================== Google Groups: http://groups.google.co.uk?hl=en
