tag:blogger.com,1999:blog-36723925597327558982024-03-13T13:23:13.336-07:00Justin GordonEnterprise TDDJustin Gordonhttp://www.blogger.com/profile/10396316553072645741noreply@blogger.comBlogger4125tag:blogger.com,1999:blog-3672392559732755898.post-5637349872498022842008-10-27T20:16:00.000-07:002008-10-27T20:42:18.848-07:00SD Best Practices 2008 Notes<a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgyKQp6HP2XKJuDbP9gQcOObJ39H_aNunJShHTiG595aVE6jNaMcIHXMLjoNmNYkH0ECQ_iuFXyzjcFPK5w-GOJbT_qxUGKYxQRjb2UsSugNTz_m84U06YDQRLuKRsjOQB-2lrSIhfh4-I/s1600-h/Join+me+at+CS.jpg"><img style="margin: 0pt 0pt 10px 10px; float: right; cursor: pointer; width: 125px; height: 125px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgyKQp6HP2XKJuDbP9gQcOObJ39H_aNunJShHTiG595aVE6jNaMcIHXMLjoNmNYkH0ECQ_iuFXyzjcFPK5w-GOJbT_qxUGKYxQRjb2UsSugNTz_m84U06YDQRLuKRsjOQB-2lrSIhfh4-I/s320/Join+me+at+CS.jpg" alt="" id="BLOGGER_PHOTO_ID_5262042993708674754" border="0" /></a>For those that attended in person, thanks for coming to <a href="https://www.cmpevents.com/SDe8/a.asp?option=G&V=3&id=558049">my talks at SD Best Practices</a>.<br /><br />If you're interested in the slides I presented, please <a href="mailto:justingordon@yahoo.com">e-mail me</a>. They always change up to the last minute!<br /><br />If you want advice on how to improve xUnit adoption on your enterprise project, feel free to <a href="mailto:justingordon@yahoo.com">e-mail me</a>! I'm happy to provide advice. I'm working on a book about adoption of xUnit testing in enterprise projects, so I want to learn as much as possible about the different obstacles out there.<br /><br />If you can, please take Scott Ambler's <a href="http://www.surveymonkey.com/s.aspx?sm=HQCO_2fXfmzVWSwxKy34uixg_3d_3d">5 minute TDD adoption survey</a>:<br /><br /><h3><a class="mozTocH3" name="mozTocId208220"></a>Recommended bestpractices for xUnits with the Database:</h3>1. Use the <a href="http://sourceforge.net/projects/dof/">Dependent Object Framework (the DOF)</a> for easy setup of database dependencies for xUnit tests.<br />2. Use JPA, possibly <a href="http://www.hibernate.org/397.html">Hibernate Entity Manager</a><br />3. Use an in-memory database, such as <a href="http://www.h2database.com/html/main.html">H2</a> <a href="http://www.justingordon.org/2008/10/in-memory-dbs-for-tdd-h2-versus-hsqldb.html">(see related blog entry)</a><br /><br />To get started on the DOF,<br />1. Review the DOF User Guide<br />2. Review the "Hello DOF" example programs.<br /><br />If you want help implementing the DOF, please <a href="mailto:justingordon@yahoo.com">contact me</a>.<br /><br />I'll be speaking at <a href="http://www.voicesthatmatter.com/craftingsoftware/">Voices that Matter</a> in San Francisco on December 3<br /><br />So Wassup with writing software without adding automated unit tests as you go along? Well, this video came to mind. The Wassup video:<br /><object width="425" height="344"><param name="movie" value="http://www.youtube.com/v/ndzWVnD7-vQ&hl=en&fs=1"><param name="allowFullScreen" value="true"><br /><embed src="http://www.youtube.com/v/ndzWVnD7-vQ&hl=en&fs=1" type="application/x-shockwave-flash" allowfullscreen="true" width="425" height="344"></embed></object>Justin Gordonhttp://www.blogger.com/profile/10396316553072645741noreply@blogger.com3tag:blogger.com,1999:blog-3672392559732755898.post-80600838302286093852008-10-27T18:57:00.000-07:002008-10-27T20:41:51.339-07:00In-Memory DBs for TDD: H2 versus HSQLDBJustin Gordon, October 27, 2008<br /><br />Use of in-memory databases can dramatically improve your ability to write xUnit tests. Should one also use H2 or HSQLDB for xUnit testing? Or some other Java open source database? My examples for the Dependent Object Framework support both H2 and HSQLDB. It is relatively simple to switch between them. Mostly, it's a matter of switching the JDBC connection string.<br /><h2>Criteria for doing database TDD:</h2>The functionality desired is<br /><ol><li><span style="font-weight: bold;">FAST</span>. <a href="http://www.h2database.com/html/performance.html">H2 claims to be the fastest</a> In a simple test I did, H2 and HSQLDB performed almost identically. </li><br /><li><span style="font-weight: bold;">DB2 or Oracle compatiblity support.</span> H2 claims to have both: <a href="http://www.h2database.com/html/features.html">Oracle and and MS SQL Server Compatiblity Mode</a>. If this works well, this is a huge win.</li><br /><li><span style="font-weight: bold;">Stability</span>: HSQLDB seems somewhat better supported as HSQLDB appears to be used in more commercial applications, so it may be better supported. In the past, Hibernate support seemed more stable. Much of this difference is probably attributable to HSQLDB being older.</li><br /><li><span style="font-weight: bold;">Ease of use</span>: H2 slightly beat out HSQLDB in this category with a simpler install that provides a shortcut to starting an in-memory database and a browser session with a<br />nice interface. Couldn't be any simpler than this! Setting up HSQLDB was definitely a bit trickier, and the UI is definitely better in H2.<br /></li></ol>Common DB features not required for TDD:<br /><ol><li>Scalability<br /></li><li>Concurrency<br /></li><li>Stability under high load<br /></li><li>Data integrity<br /><br /></li></ol>Those features are absolutely critical to your production application. However, TDD test suites run in single user mode and the tests do not even need to persist the data.<br /><br /><span style="font-weight: bold;font-size:130%;" >Annecdotes</span><br /><br />I know of one commercial software company that completely relies on H2 for their unit tests, while they deploy on Oracle.<br /><br /><span style="font-size:130%;"><span style="font-weight: bold;">References</span><br /></span><br /><a href="http://www.h2database.com/html/main.html">H2</a><br /><br /><a href="http://hsqldb.org/">HSQLDB<br /><br /></a><br /><span style="font-weight: bold;font-size:130%;" >Miscellaneous</span><br /><br /><a href="http://www.infoq.com/news/h2-released">Article on H2 by H2 creator</a>: Mueller states that H2 is faster than HSQLDB for most<br />operations and is architecturally superior. Since he wrote the original HSQLDB, he'd be well qualified to comment. Here's the summary straight out of infoq:<br /><br /><div style="margin-left: 40px;"><a href="http://hsqldb.org/">HSQLDB </a>creator Thomas Mueller has released 1.0 final of <a href="http://www.h2database.com/">H2, his pure Java database successor to HSQLDB</a>.<br />H2's focus is to be best database for the lower end (low number of concurrent connections, embedded usage). H2's features are comparable to MySQL and PostgreSQL; it has views, subqueries, triggers, clustering, role based security, encryption, user defined functions, disk and in-memory usage, embedded and client-server usage, referential integrity, scrollable result sets, schema support, transaction isolation. There are a few tools like the browser based Console application (now with auto-complete). A few things are still missing: H2 currently only offers table-level locking, full outer joins are not supported yet, the ODBC driver is only 'experimental' so far, and the standard API for distributed transactions (two-phase commit) is incomplete, however for most use cases these may not be critical.<br /></div><br /><br />Here's a good <a href="http://www.encorewiki.org/display/encore/Open+Source+Databases+Comparison">comparison of open source databases</a> by David Leung, based on the following criteria:<br /><ul><li><b>FREE</b> or <b>Open Source</b></li><li>Multiple platform support</li><li>Easy to install and use</li><li>Can be bundle in code so little or no extra installation is required</li><li>Can be scalable, i.e. load balancing, size limit, etc.</li><li>Reliable, i.e. backup, replication, etc.</li><li>Efficient, i.e. indexing, fast search, etc.</li></ul><br />He recommends, in the following order:<br /><ol><li>H2</li><li>Derby</li><li>HSQLDB</li><li>MySQL</li><li>PostgreSQL</li></ol><span style="font-weight: bold;"><span style="font-size:130%;">Summary<span style="font-weight: bold;"><span style="font-weight: bold;"><span style="font-weight: bold;"></span></span></span></span></span><br />It is not so critical which in-memory database you use as it is to simply try out using an in-memory database for your xUnit tests. H2 is a good starting point, especially with it's Oracle and SQL Server compatibility modes.Justin Gordonhttp://www.blogger.com/profile/10396316553072645741noreply@blogger.com1tag:blogger.com,1999:blog-3672392559732755898.post-28250993358898243652008-03-23T01:12:00.000-07:002008-10-27T08:23:43.749-07:00Database Dependent JUnit Tests and the “Dependent Object Framework"10/27/2008 --> Please stay tuned for an update to this article in the next couple of days.<br /><br /><o:p></o:p><span style=""><span style="font-size:130%;">Have you ever worked on a large enterprise software project (one that heavily uses a database) and wanted to add JUnit tests? And did you quickly realize that it’s easier said than done? Why is that? Want to learn a better way? If so, keep reading how a new open source project can solve this problem.</span><br /><br /></span><span style=""><o:p></o:p></span> <p class="MsoNormal" style=""><span style=""><o:p></o:p>Back in 2004, I managed to introduce a huge body of JUnit tests in my team’s project, IBM’s “</span><st1:place><st1:placename><span style="">WebSphere</span></st1:placename><span style=""> </span><st1:placename><span style="">Product</span></st1:placename><span style=""> </span><st1:placetype><span style="">Center</span></st1:placetype></st1:place><span style="">,” but the tests solely focused on the core storage layer which had few dependencies to the rest of the complicated system. Managers kept pestering for more JUnit coverage. The conventional wisdom was that we needed to refactor the code into the appropriate layers so that dependencies on the database could be isolated and “mocked out”. The conventional wisdom (and most definitely the managerial wisdom!) was that thou shall not make big code changes without lots of automated unit tests. Hmmm, this sounded eerily like “Catch 22”. We couldn’t change the code without JUnit tests and we couldn’t have JUnit tests without changing the code!</span><span style=""><o:p></o:p></span></p> <p class="MsoNormal" style=""><span style="">We resigned ourselves to the reality that we had to have JUnit tests that ran against the database. What were our options for setting up the database to run tests?</span><span style=""><o:p></o:p></span></p><br /><table class="MsoTableGrid" style="border: medium none ; border-collapse: collapse;" border="1" cellpadding="0" cellspacing="0"> <tbody><tr style=""> <td style="border: 1pt solid windowtext; padding: 0in 5.4pt; width: 77.4pt;" valign="top" width="103"> <p class="MsoNormal" style=""><b><span style="">Technique</span></b><b><span style=""><o:p></o:p></span></b></p> </td> <td style="border-style: solid solid solid none; padding: 0in 5.4pt; width: 217.8pt;" valign="top" width="290"> <p class="MsoNormal" style=""><b><span style="">Details</span></b><b><span style=""><o:p></o:p></span></b></p> </td> <td style="border-style: solid solid solid none; padding: 0in 5.4pt; width: 2.05in;" valign="top" width="197"> <p class="MsoNormal" style=""><b><span style="">Issues</span></b><b><span style=""><o:p></o:p></span></b></p> </td> </tr> <tr style=""> <td style="border-style: none solid solid; padding: 0in 5.4pt; width: 77.4pt;" valign="top" width="103"> <p class="MsoNormal" style=""><span style="">SQL Scripts</span><span style=""><o:p></o:p></span></p> </td> <td style="border-style: none solid solid none; padding: 0in 5.4pt; width: 217.8pt;" valign="top" width="290"> <p class="MsoNormal" style=""><span style="">Write inserts to populate a blank database.</span><span style=""><o:p></o:p></span></p> </td> <td style="border-style: none solid solid none; padding: 0in 5.4pt; width: 2.05in;" valign="top" width="197"> <p class="MsoNormal" style=""><span style="">Any time the database schema changes, the scripts need modification.</span><span style=""><o:p></o:p></span></p> </td> </tr> <tr style=""> <td style="border-style: none solid solid; padding: 0in 5.4pt; width: 77.4pt;" valign="top" width="103"> <p class="MsoNormal" style=""><span style="">Restore a backup of the database</span><span style=""><o:p></o:p></span></p> </td> <td style="border-style: none solid solid none; padding: 0in 5.4pt; width: 217.8pt;" valign="top" width="290"> <p class="MsoNormal" style=""><span style="">Use the UI or any means to get the database ready for the unit tests. Then save a backup copy.</span><span style=""><o:p></o:p></span></p> </td> <td style="border-style: none solid solid none; padding: 0in 5.4pt; width: 2.05in;" valign="top" width="197"> <p class="MsoNormal" style=""><span style="">Any time the database schema changes, the backup copies need to be recreated.</span><span style=""><o:p></o:p></span></p> </td> </tr> <tr style=""> <td style="border-style: none solid solid; padding: 0in 5.4pt; width: 77.4pt;" valign="top" width="103"> <p class="MsoNormal" style=""><span style="">Write Java code</span><span style=""><o:p></o:p></span></p> </td> <td style="border-style: none solid solid none; padding: 0in 5.4pt; width: 217.8pt;" valign="top" width="290"> <p class="MsoNormal" style=""><span style="">Write Java code (probably many lines) to setup the objects for the test.</span><span style=""><o:p></o:p></span></p> </td> <td style="border-style: none solid solid none; padding: 0in 5.4pt; width: 2.05in;" valign="top" width="197"> <p class="MsoNormal" style=""><span style="">Too much Java code to maintain, and bugs with the copious code.</span><span style=""><o:p></o:p></span></p> </td> </tr> </tbody></table><br /><br /><p class="MsoNormal" style=""><span style="">All of these options were painful, fragile, monolithic, and tedious. If you’ve tried any of these options, then you would agree.</span><span style=""><o:p></o:p></span></p> <p class="MsoNormal" style=""><span style=""><o:p> </o:p></span></p> <p class="MsoNormal" style=""><span style="">A co-worker and lisp aficionado, Umair Akeel, came up with a proposal that at the beginning of a test, we list the database objects that must exist for the test. Let’s suppose we are writing a test on an Invoice object and thus that test would require a Customer object, a couple Product objects, and those product objects would require a couple Manufacturer objects. What would that look like?</span><span style=""><o:p></o:p></span></p> <p class="MsoNormal" style=""><span style=""><o:p> </o:p></span></p> <p class="MsoNormal" style=""><span style="">We would have a method called “require” that would take a file name that would specify a file that would describe a given object, and the file name would also specify the object’s type and primary key. In this example, we would list the following at the beginning of the JUnit test on an Invoice:</span><span style=""><o:p></o:p></span></p> <p class="MsoNormal" style=""><span style=""><o:p> </o:p></span></p> <p class="Code" style="margin-left: 0.5in;"><span style="font-family:Courier;">require(“customer.25.xml”);<o:p></o:p></span></p> <p class="Code" style="margin-left: 0.5in;"><span style="font-family:Courier;">require(“manufacturer.12.xml”);<o:p></o:p></span></p> <p class="Code" style="margin-left: 0.5in;"><span style="font-family:Courier;">require(“manufacturer.30.xml”);<o:p></o:p></span></p> <p class="Code" style="margin-left: 0.5in;"><span style="font-family:Courier;">require(“product.13.xml”);<o:p></o:p></span></p> <p class="Code" style="margin-left: 0.5in;"><span style="font-family:Courier;">require(“product.31.xml”);<o:p></o:p></span></p> <p class="MsoNormal" style=""><span style=""><o:p> </o:p></span></p> <p class="MsoNormal" style=""><span style="">In this example, Product 13 depends on Manufacturer 12 and Product 31 depends on Manufacturer 30. The strings passed as parameters to the “require” method specify the object type and the object’s primary key, as well as a file that uniquely defines the object.</span><span style=""><o:p></o:p></span></p> <p class="MsoNormal" style=""><span style=""><o:p> </o:p></span></p> <p class="MsoNormal" style=""><span style="">I later made the suggestion that instead of having to remember to list out all dependencies (in this case, listing “manufacturer.12.xml” before “product.13.xml”), we put the dependencies of each object in its own object description file.</span><span style=""><o:p></o:p></span></p> <p class="MsoNormal" style=""><span style=""><o:p> </o:p></span></p> <p class="MsoNormal" style=""><span style="">Then we would only need this at the beginning of the test (or test fixture):</span><span style=""><o:p></o:p></span></p> <p class="Code" style="margin-left: 0.5in;"><span style="font-family:Courier;"></span></p><p class="Code" style="margin-left: 0.5in;"><span style="font-family:Courier;">require(“customer.25.xml”);<o:p></o:p></span></p> <p class="Code" style="margin-left: 0.5in;"><span style="font-family:Courier;">require(“product.13.xml”);<o:p></o:p></span></p> <p class="Code" style="margin-left: 0.5in;"><span style="font-family:Courier;">require(“product.31.xml”);</span></p><p class="Code" style="margin-left: 0.5in;"><span style="font-family:Courier;"><o:p></o:p></span></p> <p class="MsoNormal" style=""><span style=""><o:p> </o:p></span></p> <p class="MsoNormal" style=""><span style="">The “require” method is smart in that it only creates the object in the database if the object does not exist in the database, and once the object is fetched from the database, the framework keeps the database object cached in a map.</span><span style=""><o:p></o:p></span></p> <p class="MsoNormal" style=""><span style=""><o:p> </o:p></span></p> <p class="MsoNormal" style=""><span style="">This framework allowed us to be very modular in setting up objects for running a database test. That allowed us to achieve the following necessities of running JUnit tests effectively:</span><span style=""><o:p></o:p></span></p> <ol style="margin-top: 0in;" start="1" type="1"><li class="MsoNormal" style="color:black;"><span style="">Tests must run in any order, and any number of times, with the same result.</span><span style=""><o:p></o:p></span></li><li class="MsoNormal" style="color:black;"><span style="">Easy to add a new test, and run it without worrying about the state of the database.</span><span style=""><o:p></o:p></span></li></ol> <p class="MsoNormal" style=""><span style=""><o:p> </o:p></span></p> <p class="MsoNormal" style=""><span style="">We’ve got scripts to set up a blank database, ready for our customers. However, we use the “require” framework to check that the required objects for a test exist. This framework has allowed us to achieve far more legacy test coverage than we ever would have otherwise.</span><span style=""><o:p></o:p></span></p> <p class="MsoNormal" style=""><span style=""><o:p> </o:p></span></p> <p class="MsoNormal" style=""><span style="">In 2007, I got IBM’s permission to convert the technique into an open source project, which I’ve named the “Dependent Object Framework”.</span><span style=""><o:p></o:p></span></p> <p class="MsoNormal" style="margin-top: 12pt;"><span style="">The Dependent Object Framework (DOF) (</span><span style=""><a href="http://sourceforge.net/projects/dof/_">http://sourceforge.net/projects/dof/</a></span><span style="">) enables efficient JUnit testing and Test Driven Development against code that depends on objects that are persisted (e.g., database). </span><span style=""><o:p></o:p></span></p> <p class="MsoNormal" style="margin-top: 12pt;"><span style="">Let’s look at a simple example using the Dependent Object Framework. Consider the invoice example listed above. Your invoice needs a product record in the database. So you simply put this line at the top of your JUnit test:</span><span style=""><o:p></o:p></span></p> <p class="MsoNormal" style="margin-top: 12pt;"><span style=";font-family:Courier;color:black;" >Product product = (Product) DOF.require("product.13.xml");</span><span style=";font-family:Courier;color:black;" ><o:p></o:p></span></p> <p class="MsoNormal" style="margin-top: 12pt;"><span style="">What you have </span><b><span style="">not</span></b><span style=""> done is pre-load the database with a SQL script or database backup. Your test is just saying “make sure that the product record 13 exists in the database and give me that object. You know that the product record will have other records that it depends on, but you only need to specify that your test </span><b><span style="">requires</span></b><span style=""> the product record. In fact, maybe the file “product.13.xml” is used by another test, so you didn’t even need to create it.</span><span style=""><o:p></o:p></span></p> <p class="MsoNormal" style="margin-top: 12pt;"><span style="">Can it get any easier than this for specifying what your test needs on top of an unpopulated database?</span><span style=""><o:p></o:p></span></p> <p class="MsoNormal" style="margin-top: 12pt;"><span style="">The DOF makes it easy to write tests with database dependencies. Advantages include:</span><span style=""><o:p></o:p></span></p> <p class="MsoNormal" style="margin-top: 12pt;"><span style="">1. Facilitation of testing legacy enterprise code lacking JUnit tests. With the DOF, you do not need to untangle the database dependencies in order to write mock objects.</span><span style=""><o:p></o:p></span></p> <p class="MsoNormal" style="margin-top: 12pt;"><span style="">2. Easy reuse of database objects needed for unit tests. This facilitates team leverage in creating JUnit tests. The work in creating the database setup for JUnit tests is distributed and modular, versus the monolithic approach of using a SQL script or database backup.</span><span style=""><o:p></o:p></span></p> <p class="MsoNormal" style="margin-top: 12pt;"><span style="">3. Very simple to define which objects a test depends upon. Any indirect dependencies (dependencies of the dependencies) are specified in the files defining the dependent objects. Thus, a JUnit test can depend on object A, and object A might depend on object C. The test simply needs to specify object A, and the definition file for object A will specify object C.</span><span style=""><o:p></o:p></span></p> <p class="MsoNormal" style="margin-top: 12pt;"><span style="">4. Very easy to delete persistent objects created for a test. When one is tweaking tests, this is very helpful.</span><span style=""><o:p></o:p></span></p> <p class="MsoNormal" style="margin-top: 12pt;"><span style="">5. Very easy to add support for new database object types.</span><span style=""><o:p></o:p></span></p> <p class="MsoNormal" style="margin-top: 12pt;"><span style="">6. Fabulous for creating “integration” JUnit tests that run against the database and other real dependencies, just as customers will use the product. So even if you have mocked out the database for many tests, you can still leverage the DOF for running integration tests.</span><span style=""><o:p></o:p></span></p> <p class="MsoNormal" style="margin-top: 12pt;"><span style="">So how does this work?</span><span style=""><o:p></o:p></span></p> <p class="MsoNormal" style="margin-top: 12pt;"><span style="">1. You define a data file format for your object type, such as XML. </span><span style=""><o:p></o:p></span></p> <p class="MsoNormal" style="margin-top: 12pt;"><span style="">2. You write a “handler” class for this data file format. The handler class implements an interface DependentObjectHandler composed of “create(objectFileInfo)”, “get(objectFileInfo)”, and “delete(objectFileInfo).” ObjectFileInfo is a struct with 4 fields: file path that describes the object (i.e., "product.13.xml"), the object's primary key (i.e., 13), the object type (i.e., product), and the file type (i.e., xml)<br /></span></p><p class="MsoNormal" style="margin-top: 12pt;"><span style="">3. You specify the mapping of the object types to the handlers, in a file called handler_mappings.properties. For example, to specify that files named like product.13.xml map to the ProductXmlFactory class:</span><span style=";font-family:Courier;color:black;" ><o:p></o:p></span></p> <p class="MsoNormal" style="margin-top: 12pt;"><span style=";font-family:Courier;color:black;" >product.xml=myPackage.ProductXmlFactory</span><span style=";font-family:Courier;color:black;" ><o:p></o:p></span></p> <p class="MsoNormal" style="margin-top: 12pt;"><span style="">4. You create a data file for the object you want to create, named like {objectType}.{primaryKey}.{fileExtension} such as “product.13.xml”</span><span style=""><o:p></o:p></span></p> <p class="MsoNormal" style="margin-top: 12pt;"><span style="">5. The data file contains comment lines indicating its dependencies. For example, this line indicates that the product 13 depends on the manufacturer 33 existing in the database.</span><span style=";font-family:Courier;color:black;" ><o:p></o:p></span></p> <p class="MsoNormal" style="margin-top: 12pt;"><span style=";font-family:Courier;color:black;" ><!-- @require("manufacturer.33.xml") --></span><span style=";font-family:Courier;color:black;" ><o:p></o:p></span></p> <p class="MsoNormal" style="margin-top: 12pt;"><span style="">You can download the framework including the JavaDoc and an example that uses simple XML and hsqldb here: </span><span style=""><a href="http://sourceforge.net/projects/dof/_">http://sourceforge.net/projects/dof/</a></span><span style=""><o:p></o:p></span></p> <p class="MsoNormal" style="margin-top: 12pt;"><span style="">Please let me know if you find this useful or if you’d like to contribute. I’m working on extending the example to support hibernate JPA. I suspect that the project might not need to change for this support.</span><span style=""><o:p></o:p></span></p> <p class="MsoNormal" style="margin-top: 12pt;"><span style="">I’m also looking for volunteers to port this code to:</span><span style=""><o:p></o:p></span></p> <ul style="margin-top: 0in;" type="disc"><li class="MsoNormal" style="margin-top: 12pt;color:black;"><span style="">C++</span><span style=""><o:p></o:p></span></li><li class="MsoNormal" style="margin-top: 12pt;color:black;"><span style="">C#</span><span style=""><o:p></o:p></span></li><li class="MsoNormal" style="margin-top: 12pt;color:black;"><span style="">Groovy</span><span style=""><o:p></o:p></span></li><li class="MsoNormal" style="margin-top: 12pt;color:black;"><span style="">Other xUnit supported languages.</span><span style=""><o:p></o:p></span></li></ul> <p class="MsoNormal" style="margin: 12pt 0in 0.0001pt 0.25in;"><span style=""><o:p> </o:p></span></p> <p class="MsoNormal" style="margin-top: 12pt;"><span style="">I'd like to hear if you have any comments or questions on this project.</span><span style=""><o:p></o:p></span></p> <p class="MsoNormal" style="margin-top: 12pt;"><span style="">Cheers,</span><span style=""><o:p></o:p></span></p> <p class="MsoNormal" style="margin-top: 12pt;"><span style="">Justin Gordon</span><span style=""><o:p></o:p></span></p> <p class="MsoNormal">justingordon at yahoo.com</p>Justin Gordonhttp://www.blogger.com/profile/10396316553072645741noreply@blogger.com13tag:blogger.com,1999:blog-3672392559732755898.post-52698159361489987032008-03-12T20:36:00.000-07:002008-03-12T23:18:28.803-07:00Enterprise TDDWelcome to my new blog. I'm going publish thoughts on how to build enterprise software more effectively, especially with regards to test driven development.Justin Gordonhttp://www.blogger.com/profile/10396316553072645741noreply@blogger.com0