Jose, Here are a couple of things you might find interesting: * A excerpt from my book POJOs in Action on testing a persistence layer: http://www.theserverside.com/tt/articles/article.tss?l=PersistentDomain * The slide from my JavaOne talk on the same topic: http://www.chrisrichardson.net/presentations/JavaOne2006Testing_dist.ppt
The tests that access the database use a Spring application context that points to the test DB, which is typically HSQLDB. With regards to using annotated Hibernated POJOs:. there is a good case to be made that annotated POJOs are not POJOs (see http://www.aspectprogrammer.org/blogs/adrian/2004/08/when_is_a_pojo.html). In the case of a library using XML configuration might enable different persistence mechanisms to be used. Chris -- Enterprise POJO consulting - http://www.chrisrichardson.net Author, POJOs in Action - http://www.manning.com/crichardson Enterprise POJOs blog - http://chris-richardson.blog-city.com On 7/11/06, Jose Gonzalez Gomez <[EMAIL PROTECTED]> wrote:
Hi there, I would like to hear about what you're doing to test your Hibernate/EJB3 POJOs (if you're doing at all). I have a project with some of them, and I have the following concerns: First of all, I may test them just ignoring persistence (already done). No problem here, just a bunch of TestNG tests running smoothly under Maven2. I think this is important, as I'm developing a library mainly intended to be used as annotated Hibernated POJOs, but maybe people using it prefer another persistence api. What do you think? Then I thought about testing the library including the persistence stuff, but this brings some problems: Problem 1: Whenver building the project, publishing the site, etc. you must have access to a runnning database in order to perform the tests. I'm currently running a postgresql database, but it may be cumbersome for users wanting to download and hack the sources. Maybe this could be solved using some kind of embeddable database? Or maybe I could create several profiles (never done this) and activate database tests only under demand? Problem 2: Having database tests involves having configuration data written down in some configuration file (the jdbc URL, user, password, etc. hibernate.cfg.xml) or even in the pom (jdbc driver dependency). It's kind of putting in the sources of the library some information that may be only of interest to me in my current environment. How to solve this? Again using some kind of embeddable datasource for tests? Using source filters? (again, I haven't done this before, so I don't know if it's suitable) Best regards Jose
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
