Comments on: Unit testing the data access layer http://www.buunguyen.net/blog/unit-testing-the-data-access-layer.html Thoughts on software development and project management Thu, 20 Nov 2008 23:16:35 +0000 http://wordpress.org/?v=2.6.2 By: Unit test your layered architecture | Solution Hacker http://www.buunguyen.net/blog/unit-testing-the-data-access-layer.html#comment-29416 Unit test your layered architecture | Solution Hacker Mon, 18 Feb 2008 11:55:41 +0000 http://www.buunguyen.net/blog/unit-testing-the-data-access-layer.html#comment-29416 [...] http://www.buunguyen.net/blog/unit-testing-the-data-access-layer.html [...] [...] http://www.buunguyen.net/blog/unit-testing-the-data-access-layer.html [...]

]]> By: papo http://www.buunguyen.net/blog/unit-testing-the-data-access-layer.html#comment-14652 papo Wed, 24 Oct 2007 11:57:50 +0000 http://www.buunguyen.net/blog/unit-testing-the-data-access-layer.html#comment-14652 just a link to a book (maybe the one your were thinking of in the post incipit..) : Test Driven: TDD and Acceptance TDD for Java Developers, by Lasse Koskela http://www.amazon.com/Test-Driven-Acceptance-Java-Developers/dp/1932394850 it`s chapter on testing a DAL follow the same ideas you pointed out. it`s for Java, but still useful for any other platform (I`m a .NET guy) bye -papo- just a link to a book (maybe the one your were thinking of in the post incipit..) :

Test Driven: TDD and Acceptance TDD for Java Developers, by Lasse Koskela
http://www.amazon.com/Test-Driven-Acceptance-Java-Developers/dp/1932394850

it`s chapter on testing a DAL follow the same ideas you pointed out. it`s for Java, but still useful for any other platform (I`m a .NET guy)

bye
-papo-

]]> By: Buu Nguyen http://www.buunguyen.net/blog/unit-testing-the-data-access-layer.html#comment-12445 Buu Nguyen Tue, 02 Oct 2007 04:25:04 +0000 http://www.buunguyen.net/blog/unit-testing-the-data-access-layer.html#comment-12445 @Robert: thanks for noticing, it's indeed another good use of DbUnit. @Rob: I agree, hitting the database, either in-memory or production is much better than the mock technique. Also, I have accessed to the links but seem not to understand the approach very well. It would be great if you can provide some more information (or links). Thanks! @James: good approach on the Oracle XE. If Hibernate is used for the DAL, then leveraging it as a data populator is an good and efficient approach. Otherwise, DbUnit is good to use. @Robert: thanks for noticing, it’s indeed another good use of DbUnit.

@Rob: I agree, hitting the database, either in-memory or production is much better than the mock technique. Also, I have accessed to the links but seem not to understand the approach very well. It would be great if you can provide some more information (or links). Thanks!

@James: good approach on the Oracle XE. If Hibernate is used for the DAL, then leveraging it as a data populator is an good and efficient approach. Otherwise, DbUnit is good to use.

]]> By: James http://www.buunguyen.net/blog/unit-testing-the-data-access-layer.html#comment-12415 James Mon, 01 Oct 2007 18:49:42 +0000 http://www.buunguyen.net/blog/unit-testing-the-data-access-layer.html#comment-12415 I largely agree. I mainly work in an oracle shop. When I test DAO classes, I use a local database. Each dev uses Oracle XE (which doesn't require any more than 10 minutes to install), and every project maintains an ant sql task to build/drop the database schemas. Script and schema is managed by a DM tool like ER studio. I would rather use the REAL database vendor since any non trivial application will find itself using proprietary sql at some point. Hence moving from in memory to another would be too much trouble, since oracle sql can be non standard. For test setup, on a jpa/hibernate project, I find using hibernate itself as a row populator is a nice way to make sure mappings work, besides its incredible payback for taking time to map properly. I also use the spring mock test cases, since they make it easy to start a transaction, and rollback at end of test, in addition to caching the jpa configuration, which saves a lot of time. I largely agree. I mainly work in an oracle shop. When I test DAO classes, I use a local database. Each dev uses Oracle XE (which doesn’t require any more than 10 minutes to install), and every project maintains an ant sql task to build/drop the database schemas. Script and schema is managed by a DM tool like ER studio. I would rather use the REAL database vendor since any non trivial application will find itself using proprietary sql at some point. Hence moving from in memory to another would be too much trouble, since oracle sql can be non standard.

For test setup, on a jpa/hibernate project, I find using hibernate itself as a row populator is a nice way to make sure mappings work, besides its incredible payback for taking time to map properly.

I also use the spring mock test cases, since they make it easy to start a transaction, and rollback at end of test, in addition to caching the jpa configuration, which saves a lot of time.

]]> By: Rob Di Marco http://www.buunguyen.net/blog/unit-testing-the-data-access-layer.html#comment-12401 Rob Di Marco Mon, 01 Oct 2007 12:13:33 +0000 http://www.buunguyen.net/blog/unit-testing-the-data-access-layer.html#comment-12401 Good article. My thoughts: -- I greatly prefer using an in-memory database to the mock database. Using the mock database can be a real pain to debug and maintain. With the in-memory database option, it is much easier to replicate both the DDL and the data used by your application. With the mock data set, you sometimes "think" you have it set up the same as your database, but subtle bugs may make that not so. -- If you are using the Java Persistence API / EJB 3, there are some really cool things that you can do using embedded containers to help simulate the whole transaction. It makes for very easy setup, configuration and execution. Having used these techniques, I could never imagine developing a J2EE app without an embedded container unit test. The presentations are available at http://www.innovationontherun.com/presentations/ and I would be happy to go into more detail if anyone is interested. Good article. My thoughts:

– I greatly prefer using an in-memory database to the mock database. Using the mock database can be a real pain to debug and maintain. With the in-memory database option, it is much easier to replicate both the DDL and the data used by your application. With the mock data set, you sometimes “think” you have it set up the same as your database, but subtle bugs may make that not so.

– If you are using the Java Persistence API / EJB 3, there are some really cool things that you can do using embedded containers to help simulate the whole transaction. It makes for very easy setup, configuration and execution. Having used these techniques, I could never imagine developing a J2EE app without an embedded container unit test. The presentations are available at http://www.innovationontherun.com/presentations/ and I would be happy to go into more detail if anyone is interested.

]]> By: Mike http://www.buunguyen.net/blog/unit-testing-the-data-access-layer.html#comment-12362 Mike Mon, 01 Oct 2007 04:06:41 +0000 http://www.buunguyen.net/blog/unit-testing-the-data-access-layer.html#comment-12362 Nicely written. I agree with it all 100%. I think the hardest part (with hibernate and hsqldb) is getting data in to the db to start with. I've looked at DbUnit a few times but have never ventured into setting it up. It looks like more work than its worth. Although, I must say, the comment above does look simple. Robert, I'm going to give it another whirl. Thanks all. Nicely written. I agree with it all 100%. I think the hardest part (with hibernate and hsqldb) is getting data in to the db to start with. I’ve looked at DbUnit a few times but have never ventured into setting it up. It looks like more work than its worth. Although, I must say, the comment above does look simple. Robert, I’m going to give it another whirl. Thanks all.

]]> By: Robert Murray http://www.buunguyen.net/blog/unit-testing-the-data-access-layer.html#comment-12331 Robert Murray Sun, 30 Sep 2007 15:41:48 +0000 http://www.buunguyen.net/blog/unit-testing-the-data-access-layer.html#comment-12331 You mention DbUnit for data population purposes, but DbUnit also quite capable for results testing also. Example code below (from the docs) - very easy to code and understand, though setup does require some xml tinkering beforehand. <pre>// Fetch database data after executing your code IDataSet databaseDataSet = getConnection().createDataSet(); ITable actualTable = databaseDataSet.getTable("TABLE_NAME"); // Load expected data from an XML dataset IDataSet expectedDataSet = new FlatXmlDataSet( new File("expectedDataSet.xml")); ITable expectedTable = expectedDataSet.getTable("TABLE_NAME"); // Assert actual database table match expected table Assertion.assertEquals(expectedTable, actualTable); </pre> You mention DbUnit for data population purposes, but DbUnit also quite capable for results testing also. Example code below (from the docs) - very easy to code and understand, though setup does require some xml tinkering beforehand.

// Fetch database data after executing your code
IDataSet databaseDataSet = getConnection().createDataSet();
ITable actualTable = databaseDataSet.getTable("TABLE_NAME");

// Load expected data from an XML dataset
IDataSet expectedDataSet = new FlatXmlDataSet(
                       new File("expectedDataSet.xml"));
ITable expectedTable = expectedDataSet.getTable("TABLE_NAME");

// Assert actual database table match expected table
Assertion.assertEquals(expectedTable, actualTable);
]]>