Eric Hauser’s Blog

I have had the privilege of doing some work for Ayende for the past month to add support for Hibernate to his excellent NHibernate Profiler.  What does this mean exactly?  Well, Hibernate is now supported as a first class citizen in the profiler.  We have tried to make sure that there is a 1:1 feature mapping between the NHibernate and Hibernate support.  I am happy to report that all applicable warnings and information that you receive for NHibernate is also displayed for Hibernate.  There are of course differences between NHibernate and Hibernate — such as Hibernate does not support statement level batching options, multiquery, or future queries – which is reflected in the documentation.

Since many developers use Hiberante with Spring, we have tried to make Spring integration as seamless as possible.  If you are using  Hibernate with Spring, configuring your application to be profiled is as simple adding a JAR and a custom attribute to your Spring configuration.  Here you can see where I have added support for profiling to an Appfuse demo project:

   1: <!-- Hibernate SessionFactory -->

   2: <bean id="sessionFactory" class="org.springframework.orm.hibernate3.annotation.AnnotationSessionFactoryBean">

   3:     <property name="dataSource" ref="dataSource"/>

   4:     <property name="configLocation" value="classpath:hibernate.cfg.xml"/>

   5:     <property name="hibernateProperties">

   6:         <value>

   7:             hibernate.dialect=${hibernate.dialect}

   8:             hibernate.query.substitutions=true 'Y', false 'N'

   9:             hibernate.cache.use_second_level_cache=true

  10:             hibernate.cache.provider_class=org.hibernate.cache.EhCacheProvider

  11:         </value>

  12:         <!-- Turn batching off for better error messages under PostgreSQL -->

  13:         <!-- hibernate.jdbc.batch_size=0 -->

  14:     </property>

  15:     <hprof:profiler />

  16: </bean>

This, of course, is just one of the many different ways that you can configure the profiler.  Here is a screenshot of me profiling an Appfuse application.  The top few sessions are profiling unit tests and the remaining sessions (with the URLs) are profiling the web application:

Currently, the product is in closed beta and we are looking for beta testers.  If you are interested, then please contact either Ayende through his blog and he will get you all setup.  Other places you can provide feedback are the user group and the feedback site.  Although I may be a little biased, I think this application can add a lot of value for anyone who is using NHibernate and Hibernate.

I was recently talking with a coworker who said that they write their unit tests in Groovy because unit tests are not production code so the language does not matter.  Of course, I think Groovy is a fine choice for producation applications, but I am ignoring that point for the purposes of this post.  I could not disagree with my coworkers comments more.  Unit tests are as important as your code itself.  I do not think that comment needs more explanation than that, only that I find it interesting that many people still see unit tests as a second class citizen in a code base.

The other interesting thing is that the current goal is to get 80% unit tests passing on all projects (the projects that I work on have 100% all the time, otherwise I would lose my mind).  This is a strategy I disagree with.  Let’s say that over time your project has gotten to a state where you only have 50% of the unit tests passing.  As far as I am concerned, this is equivalent to having 0% of the tests passing.  Why?  Because developers see tests in two colors: red and green.  You will quickly find that the 50% will continue to down because no one is actually noticing that they are breaking tests as they are making code changes.  On a few large projects I have worked on, I have seen where a single failing unit test quickly becomes 20. 

Assuming that because of business goals and quantity of tests to fix, that just fixing all of the tests immediately is not an option.  A much better strategy, in my opinion, would be to ignore the tests that are failing and say that all projects must have 100% unit tests passing.  Then, make your goal to be to work your way down from 50% ignored tests to 0% ignored tests over a reasonable period of time.