Comments on: JPA implementation patterns: Testing http://blog.xebia.com/2009/07/11/jpa-implementation-patterns-testing/ Thu, 18 Mar 2010 13:27:36 +0100 http://wordpress.org/?v=2.8.4 hourly 1 By: Gene De Lisa http://blog.xebia.com/2009/07/11/jpa-implementation-patterns-testing/comment-page-1/#comment-92318 Gene De Lisa Thu, 20 Aug 2009 12:24:09 +0000 http://blog.xebia.com/?p=2528#comment-92318 "(Ever tried to refactor 50+ insert statements?)." Yes. No big deal. You can write this thing called a "program" to regenerate your insert statements. “(Ever tried to refactor 50+ insert statements?).”

Yes. No big deal.
You can write this thing called a “program” to regenerate your insert statements.

]]> By: JPA Implementation Patterns « Fernando Franzini Java Blog http://blog.xebia.com/2009/07/11/jpa-implementation-patterns-testing/comment-page-1/#comment-92103 JPA Implementation Patterns « Fernando Franzini Java Blog Thu, 16 Jul 2009 12:43:24 +0000 http://blog.xebia.com/?p=2528#comment-92103 [...] Testing [...] [...] Testing [...]

]]> By: Lars Vonk http://blog.xebia.com/2009/07/11/jpa-implementation-patterns-testing/comment-page-1/#comment-92065 Lars Vonk Sun, 12 Jul 2009 12:26:47 +0000 http://blog.xebia.com/?p=2528#comment-92065 Hi Vincent, Luckily I have just finished <a href="http://blog.larsvonkconsultancy.nl/2009/07/tdd-tips/" rel="nofollow">a blog with some TDD tips</a> :-). I think one of the main aspects is that in most applications it does not really matter what storage technology you use. As long as you define your tests in a high level language you can easily change from in-memory to Oracle for instance. The good thing is that whenever you change you have tests that proof your code is still working. Another tip specifically for inserting test data in the database: Don't use SQL insert scripts and stay away from tools like DBUnit where you need to define your testdata in XML. Why? Because this really gets in your way when needing to refactor the database. (Ever tried to refactor 50+ insert statements?). What I recommend is to setup your test data in java objects using Builder and <a href="http://martinfowler.com/bliki/ObjectMother.html" rel="nofollow">ObjectMothers</a>, then use your dao's to insert those into the database. Hi Vincent,

Luckily I have just finished a blog with some TDD tips :-) . I think one of the main aspects is that in most applications it does not really matter what storage technology you use. As long as you define your tests in a high level language you can easily change from in-memory to Oracle for instance. The good thing is that whenever you change you have tests that proof your code is still working.

Another tip specifically for inserting test data in the database: Don’t use SQL insert scripts and stay away from tools like DBUnit where you need to define your testdata in XML. Why? Because this really gets in your way when needing to refactor the database. (Ever tried to refactor 50+ insert statements?).
What I recommend is to setup your test data in java objects using Builder and ObjectMothers, then use your dao’s to insert those into the database.

]]>