package com.sourceallies.logging;
 
import static org.junit.Assert.assertEquals;
import static org.junit.Assert.assertFalse;
import static org.junit.Assert.assertTrue;
 
import java.sql.Timestamp;
import java.util.Calendar;
import java.util.Date;
import java.util.List;
 
import javax.annotation.Resource;
 
import org.apache.commons.lang.time.DateUtils;
import org.hibernate.Criteria;
import org.hibernate.SessionFactory;
import org.hibernate.classic.Session;
import org.junit.Before;
import org.junit.Test;
import org.junit.runner.RunWith;
import org.springframework.test.context.ContextConfiguration;
import org.springframework.test.context.junit4.SpringJUnit4ClassRunner;
import org.springframework.test.context.transaction.TransactionConfiguration;
import org.springframework.transaction.annotation.Transactional;
 
import com.sourceallies.Person;
 
@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration
@TransactionConfiguration(defaultRollback=false)
public class HibernateDateTimeTest {
 
	@Resource
	private SessionFactory sessionFactory;
 
	private Session currentSession;
 
	private Date birthDateWithTime;
	private Date birthDateWithoutTime;
	private Date createDate;
	private Date modifyDate;
 
	@Before
	public void setUp() throws Exception{
		currentSession = sessionFactory.getCurrentSession();
		birthDateWithTime = new Date();
		birthDateWithoutTime = DateUtils.truncate(birthDateWithTime, Calendar.DATE);
		createDate = new Date();
		modifyDate = new Date();
	}
 
	@Test
	@Transactional
	public void testSave(){
		Person person = new Person("testFirst", "testLast", 
                      birthDateWithTime, createDate, modifyDate);
 
		assertFalse(person.getBirthDate() instanceof Timestamp);
		assertFalse(person.getCreateDate() instanceof Timestamp);
		assertFalse(person.getModifyDate() instanceof Timestamp);
 
		saveOrUpdate(person);
	}
 
	@Test
	@Transactional
	public void testFind(){
		List<Person> people = findAll();
 
		assertEquals(1, people.size());
		Person foundPerson = people.get(0);
 
		assertTrue(foundPerson.getBirthDate() instanceof Date);
		assertTrue(foundPerson.getCreateDate() instanceof Timestamp);
		assertTrue(foundPerson.getModifyDate() instanceof Timestamp);
 
		assertFalse(foundPerson.getBirthDate().equals(birthDateWithTime));
		assertTrue(foundPerson.getBirthDate().equals(birthDateWithoutTime));
		assertFalse(foundPerson.getCreateDate().equals(createDate));
		assertFalse(foundPerson.getModifyDate().equals(modifyDate));
	}
 
	public void saveOrUpdate(Person person) {
		currentSession.saveOrUpdate(person);
		currentSession.flush();
	}
 
	@SuppressWarnings("unchecked")
	private List<Person> findAll() {
		Criteria criteria = currentSession.createCriteria(Person.class);
		List<Person> people = criteria.list();
		return people;
	}
}

Here is the mapping for person.

...
@Entity
public class Person {
 
	@Id
	@GeneratedValue(strategy=GenerationType.AUTO)
	private Long id = -1L;
 
	@Column
	private String firstName;
 
	@Column
	private String lastName;
 
	@Column
	@Type(type="date")
	private Date birthDate;
 
	@Column
	@Type(type="timestamp")
	private Date createDate;
 
	@Column
	private Date modifyDate;
	...
}

There are three Date fields: ‘birthdate’, ‘createDate’, and ‘modifyDate’. The fields ‘birthDate’ and ‘createDate’ have a specified Type. The field ‘modifyDate’ however, does not have a specified Type. The generated SQL from Hibernate is as follows.

CREATE TABLE Person (id bigint generated BY DEFAULT AS identity (start WITH 1), 
birthDate date, createDate timestamp, firstName varchar(255), 
lastName varchar(255), modifyDate timestamp, PRIMARY KEY (id))

We see that Hibernate created ‘birthDate’ as a ‘Date’ and the other two were created as a ‘Timestamp’. The primary difference between ‘Date’ and ‘Timestamp’ in SQL is that ‘Timestamp’ holds the date and time while the ‘Date’ only holds the date.

At first glance this is not a big deal, but let’s take a closer look at the test.

 
	@Test
	@Transactional
	public void testSave(){
		Person person = new Person("testFirst", "testLast", 
                           birthDateWithTime, createDate, modifyDate);
 
		assertFalse(person.getBirthDate() instanceof Timestamp);
		assertFalse(person.getCreateDate() instanceof Timestamp);
		assertFalse(person.getModifyDate() instanceof Timestamp);
 
		saveOrUpdate(person);
	}

Person is created with three Dates that all include date and time values.

	@Test
	@Transactional
	public void testFind(){
		List<Person> people = findAll();
 
		assertEquals(1, people.size());
		Person foundPerson = people.get(0);
 
		assertTrue(foundPerson.getBirthDate() instanceof Date);
		assertTrue(foundPerson.getCreateDate() instanceof Timestamp);
		assertTrue(foundPerson.getModifyDate() instanceof Timestamp);
 
		assertFalse(foundPerson.getBirthDate().equals(birthDateWithTime));
		assertTrue(foundPerson.getBirthDate().equals(birthDateWithoutTime));
		assertFalse(foundPerson.getCreateDate().equals(createDate));
		assertFalse(foundPerson.getModifyDate().equals(modifyDate));
	}

When Hibernate retrieves a Person from the database the ‘createDate’ and ‘modifyDate’ have been converted to Timestamps. At first glance this doesn’t appear to be a big deal. java.sql.Timestamp extends java.util.Date. But why are they not equal. I found a helpful answer to this question in Effective Java (2nd Edition) page 41.

There are some classes in the Java platform libraries that do extend an instantiable
class and add a value component. For example, java.sql.Timestamp
extends java.util.Date and adds a nanoseconds field. The equals implementation
for Timestamp does violate symmetry and can cause erratic behavior if
Timestamp and Date objects are used in the same collection or are otherwise intermixed.
The Timestamp class has a disclaimer cautioning programmers against
mixing dates and timestamps. While you won’t get into trouble as long as you
keep them separate, there’s nothing to prevent you from mixing them, and the
resulting errors can be hard to debug. This behavior of the Timestamp class was a
mistake and should not be emulated. (Bloch, Effective Java, 2nd Ed.)

If you want to read more about ‘equals’ read chapter 3, Item 8 in Effective Java (2nd Edition). Apart from a hack there are two primary ways to solve this issue. The first way involves typing ‘createDate’ and ‘modifyDate’ to Timestamp.

	...
	@Column
	@Type(type="date")
	private Date birthDate;
 
	@Column
	private Timestamp createDate;
 
	@Column
	private Timestamp modifyDate;
        ...

The second approach uses a custom UserType. Here is a custom UserType that converts Timestamp to Date and vise versa. There is a side effect with this solution. Converting Timestamp to Date drops the nanosecond precision. If this is not acceptable then the previous solution should be used.

package com.sourceallies;
 
import java.io.Serializable;
import java.sql.PreparedStatement;
import java.sql.ResultSet;
import java.sql.SQLException;
import java.sql.Timestamp;
import java.sql.Types;
import java.util.Date;
 
import org.hibernate.HibernateException;
import org.hibernate.usertype.UserType;
 
public class DateTimeUserType  implements UserType {
 
	@Override
	public int[] sqlTypes() {
		 return new int[]{Types.TIMESTAMP};
	}
 
	@SuppressWarnings("rawtypes")
	@Override
	public Class returnedClass() {
		return Date.class;
	}
 
	@Override
	public boolean equals(Object x, Object y) throws HibernateException {
		 return x == y || !(x == null || y == null) && x.equals(y);
	}
 
	@Override
	public int hashCode(Object x) throws HibernateException {
		return x.hashCode();
	}
 
	@Override
	public Object nullSafeGet(ResultSet rs, String[] names, Object owner)
			throws HibernateException, SQLException {
		Timestamp timestamp = rs.getTimestamp(names[0]);
        if (rs.wasNull()) {
            return null;
        }
        return new Date(timestamp.getTime());
	}
 
	@Override
	public void nullSafeSet(PreparedStatement st, Object value, int index)
			throws HibernateException, SQLException {
        if (value == null) {
            st.setNull(index, Types.TIMESTAMP);
        }
        else {
            Date date = (Date) value;
            Timestamp timestamp = new Timestamp(date.getTime());
            st.setTimestamp(index, timestamp);
        }
	}
 
	@Override
	public Object deepCopy(Object value) throws HibernateException {
		return value;
	}
 
	@Override
	public boolean isMutable() {
		return false;
	}
 
	@Override
	public Serializable disassemble(Object value) throws HibernateException {
		 return (Serializable) value;
	}
 
	@Override
	public Object assemble(Serializable cached, Object owner)
			throws HibernateException {
		return cached;
	}
 
	@Override
	public Object replace(Object original, Object target, Object owner)
			throws HibernateException {
		return original;
	}
}

Here is the way to use it in the Person class.

@Entity
@TypeDefs({
		@TypeDef(name="dateTimeUserType", typeClass=DateTimeUserType.class)
})
public class Person {
	...
	@Column
	@Type(type="date")
	private Date birthDate;
 
	@Column
	@Type(type="dateTimeUserType")
	private Date createDate;
 
	@Column
	@Type(type="dateTimeUserType")
	private Date modifyDate;
        ...

Either of these solutions will prevent the ‘equals’ issue that we encountered before. This issue is not a Hibernate issue it is truly a Java issue as is stated in Effective Java (2nd Edition). Hibernate can be challenging enough without these subtle issues that are easy to miss until a bug is reported.

Here is the complete code. Hibernate Logging Zip .

In this article I will show you how to add a simple logger to Hibernate.

Start with a Test

As an avid TDD practitioner I will of coarse start with a test. Here is the final version of the test that I used to drive my code.

package com.sourceallies.logging;
 
import static org.junit.Assert.assertEquals;
import static org.mockito.Mockito.mock;
import static org.mockito.Mockito.verify;
import static org.mockito.Mockito.verifyNoMoreInteractions;
 
import java.util.Date;
import java.util.List;
 
import javax.annotation.Resource;
 
import org.apache.commons.logging.Log;
import org.hibernate.Criteria;
import org.hibernate.SessionFactory;
import org.hibernate.classic.Session;
import org.junit.Before;
import org.junit.Test;
import org.junit.runner.RunWith;
import org.springframework.test.context.ContextConfiguration;
import org.springframework.test.context.junit4.SpringJUnit4ClassRunner;
import org.springframework.transaction.annotation.Transactional;
 
import com.sourceallies.Person;
 
@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration
public class HibernateInterceptorTest {
 
	@Resource
	private SessionFactory sessionFactory;
 
	@Resource
	private HibernateInterceptor hibernateInterceptor;
 
	private Session currentSession;
 
	private Log logger;
 
	private static final Date NOW = new Date();
 
	@Before
	public void setUp(){
		logger = mock(Log.class);
		currentSession = sessionFactory.getCurrentSession();
		hibernateInterceptor.setLogger(logger);
	}
 
	@Test
	@Transactional
	public void testSaveLogging(){
		saveOrUpdate(createPerson());
 
		assertEquals(1, findAll().size());
 
		verify(logger).info("Saving Person [firstName=testFirst, lastName=testLast, birthDate=" + NOW + "].");
		verifyNoMoreInteractions(logger);
	}
 
	@Test
	@Transactional
	public void testUpdateLogging(){
		saveOrUpdate(createPerson());
 
		List<Person> people = findAll();
 
		assertEquals(1, people.size());
 
		Person firstPerson = people.get(0);
		firstPerson.setFirstName("testFirst2");
 
		saveOrUpdate(firstPerson);
 
		currentSession.flush();
 
		verify(logger).info("Saving Person [firstName=testFirst, lastName=testLast, birthDate=" + NOW + "].");	
		verify(logger).info("Updating Person [firstName=testFirst2, lastName=testLast, birthDate=" + NOW + "].");	
		verifyNoMoreInteractions(logger);
	}
 
	@Test
	@Transactional
	public void testDeleteLogging(){
		saveOrUpdate(createPerson());
 
		List<Person> people = findAll();
 
		assertEquals(1, people.size());
 
		Person firstPerson = people.get(0);
 
		delete(firstPerson);
 
		currentSession.flush();
 
		verify(logger).info("Saving Person [firstName=testFirst, lastName=testLast, birthDate=" + NOW + "].");	
		verify(logger).info("Deleting Person [firstName=testFirst, lastName=testLast, birthDate=" + NOW + "].");	
		verifyNoMoreInteractions(logger);
	}
 
	@Transactional
	public void saveOrUpdate(Person person) {
		currentSession.saveOrUpdate(person);
		currentSession.flush();
	}
 
	@Transactional
	public void delete(Person person) {
		currentSession.delete(person);
	}
 
	@SuppressWarnings("unchecked")
	private List<Person> findAll() {
		Criteria criteria = currentSession.createCriteria(Person.class);
		List<Person> people = criteria.list();
		return people;
	}
 
 
	private Person createPerson() {
		Person person = new Person("testFirst", "testLast", NOW);
		return person;
	}
}

I used a mock logger to gather information from the interceptor.

Spring Configuration

Here is the configuration required for the interceptor.

 
	<bean id="sessionFactory" class="org.springframework.orm.hibernate3.annotation.AnnotationSessionFactoryBean">
                ...
		<property name="dataSource" ref="dataSource" />
		<property name="entityInterceptor" ref="hibernateInterceptor"/>
	</bean>
 
	<bean id="transactionManager" class="org.springframework.orm.hibernate3.HibernateTransactionManager">
		<property name="sessionFactory" ref="sessionFactory" />
	</bean>
         ...	
	<context:component-scan base-package="com.sourceallies" />
        ...

The ‘entityInterceptor’ property on the ’sessionFactory’ takes a Hibernate interceptor.

Entity

@Entity
public class Person {
 
	@Id
	@GeneratedValue(strategy=GenerationType.AUTO)
	private Long id = -1L;
 
	@Column
	private String firstName;
 
	@Column
	private String lastName;
 
	@Column
	private Date birthDate;
...
	@Override
	public String toString() {
		return "Person [firstName=" + firstName + ", lastName="
				+ lastName + ", birthDate=" + birthDate + "]";
	}
}

For this example you need to implement the ‘toString’ method on the entity being logged.

Interceptor

Here is the interceptor code.

package com.sourceallies.logging;
 
import java.io.Serializable;
 
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
import org.hibernate.EmptyInterceptor;
import org.hibernate.type.Type;
import org.springframework.stereotype.Component;
 
@Component
public class HibernateInterceptor extends EmptyInterceptor {
 
	private static final long serialVersionUID = 1L;
	private Log logger = LogFactory.getLog(HibernateInterceptor.class);
 
	@Override
	public void onDelete(Object entity, Serializable id, Object[] state,
			String[] propertyNames, Type[] types) {
		log("Deleting", id, entity);
		super.onDelete(entity, id, state, propertyNames, types);
	}
 
	@Override
	public boolean onFlushDirty(Object entity, Serializable id,
			Object[] currentState, Object[] previousState,
			String[] propertyNames, Type[] types) {
		log("Updating", id, entity);
		return super.onFlushDirty(entity, id, currentState, previousState,
				propertyNames, types);
	}
 
	@Override
	public boolean onSave(Object entity, Serializable id, Object[] state,
			String[] propertyNames, Type[] types) {
		log("Saving", id, entity);
		return super.onSave(entity, id, state, propertyNames, types);
	}
 
	protected void setLogger(Log logger) {
		this.logger = logger;
	}
 
	private void log(String action, Serializable id, Object entity) {
		logger.info(action + " " + entity + ".");
	}
}

While the ‘onSave’ and ‘onDelete’ methods are clearly named the ‘onUpdate’ method appears to be missing. With a little research it quickly becomes obvious that ‘onFlushDirty’ is used for updates.

Logging database activity is this simple.

Here is the complete code. Hibernate Logging Zip

… Failure to do so will result in a violation of the general contract for Object.hashCode, which will
prevent your class from functioning properly in conjunction with all hash-based
collections, including HashMap, HashSet, and Hashtable. (Bloch, Effective Java, 2nd Ed.)


If you’re like me, you like to see a problem in running code. Well here you go.

	@Test
	public void testHashMapRetrieval_WithoutHashCode(){
		PersonWithoutHashCode person = new PersonWithoutHashCode("first", "last");
		PersonWithoutHashCode person2 = new PersonWithoutHashCode("first", "last");
		Map<PersonWithoutHashCode, String> map = new HashMap<PersonWithoutHashCode, String>();
		map.put(person, "friend");
 
		assertNull(map.get(person2));
	}
 
	@Test
	public void testHashMapRetrieval_WithHashCode(){
		PersonWithHashCode person = new PersonWithHashCode("first", "last");
		PersonWithHashCode person2 = new PersonWithHashCode("first", "last");
		Map<PersonWithHashCode, String> map = new HashMap<PersonWithHashCode, String>();
		map.put(person, "friend");
 
		assertNotNull(map.get(person2));
	}

Two equivalent ‘PersonWithoutHashCode’ instances are not considered equivalent when the ‘get’ method is called on HashMap. On the other hand the ‘PersonWithHashCode’ instances are considered equivalent for the same method.

While you can implment equals() and hashCode() by hand or generate them with your IDE, you might consider using the Objects class within the Guava Libraries. Here is the Person class using Guava.

	@Override
	public int hashCode() {
		return Objects.hashCode(firstName, lastName);
	}
 
	@Override
	public boolean equals(Object obj) {
		if (this == obj)
			return true;
		if (obj == null)
			return false;
		if (getClass() != obj.getClass())
			return false;
		PersonWithGuava other = (PersonWithGuava) obj;
		return Objects.equal(firstName, other.firstName) 
				&& Objects.equal(lastName, other.lastName);
	}

Here’s the test for this new code.

	@Test
	public void testHashMapRetrieval_WithGuava(){
		PersonWithGuava person = new PersonWithGuava("first", "last");
		PersonWithGuava person2 = new PersonWithGuava("first", "last");
		Map<PersonWithGuava, String> map = new HashMap<PersonWithGuava, String>();
		map.put(person, "friend");
 
		assertNotNull(map.get(person2));
	}

So why use this? This helps make our code DRY. Much of the generated code for the ‘hashCode()’ and ‘equals()’ method can be encapsulated. The Guava Library has done just that for us. If the implementation needs to be changed it can be updated in one place.

Now if you’re like me, you are lazy. As a lazy person I ask myself, “Do I want to write code that I can generate?”. My initial thought is “no”. Luckily you can use this new library and continue to generate your ‘equals()’, ‘hashCode()’ and even your ‘toString()’ methods. Simply add the Guava Eclipse plugin to your favorite version of Eclipse and voila.

This plugin adds new menu options.

This is the code that the plugin generated for the Person class.

	@Override
	public int hashCode(){
		return Objects.hashCode(firstName, lastName);
	}
 
	@Override
	public boolean equals(Object object){
		if (object instanceof PersonWithGuava) {
			PersonWithGuava that = (PersonWithGuava) object;
			return Objects.equal(this.firstName, that.firstName)
				&& Objects.equal(this.lastName, that.lastName);
		}
		return false;
	}

While we all know that we must override ‘hashCode()’ and ‘equals()’ together, we also know that we should eliminate duplication in our code and encapsulate common functionality. Install the Guava plugin today and remove another piece of duplication from your code.

Please read the comments below before you use this plugin.

Here’s the complete code HashCode.

First thing I did was to take a heap dump.

I selected the classes and I see

Well THAT was not helpful. It turns out that the leak is in a class that only has one instance and it is holding onto thousands of objects.
Then on the summary page I notice the “Find 20 biggest objects by retained size:”.

I click it and a long time later I see

Shazam! There it is! In this faked up example I built there is a single Stack instance but it’s retained size is huge. That because VisualVM computed not just the size of that object but the sizes of all of the objects it was holding onto. How sweet is that. I found my memory leak in like 5 minutes.

Another useful tool!

Overview

What is Maven?

Maven is a software project management and comprehension tool that includes: build tools, dependency management, project reporting and much more.  I say “much more” because at the core Maven is a plugin execution framework.  There are plugins supported by the Maven project (http://maven.apache.org/plugins/index.html), plugins supported by Mojo Project (http://mojo.codehaus.org/plugins.html), and third party plugins.  If you can find or write a plugin, Maven can run it.

Plugins

Plugins are configured to run during specific phases in the Maven lifecycle.  The high-level phases that make up the build lifecycle include: validation, compile, test, package, integration-test, verify, install, and deploy.  An exhaustive list of build phases can be found at http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html#Lifecycle_Reference.

Why not Ant and Ivy?

People always gravitate to this question of whether Maven is better than Ant and Ivy.  Unfortunately this is not a fare comparison.  Ant is a build tool and Ivy is a dependency management tool.  Maven is not just a build tool or just a dependency management tool.  On the contrary, Maven is a project management tool that embodies software development best practices.

To illustrate this point I will share a story from my early years in software development.  Our shop used Ant without Ivy.  Ivy didn’t become a full fledged Apache project until October, 2007.  Each team had their own Ant build.  As we began to move from team to team we had to find out which targets needed to be run.  Over time we decided on a set of names that every team needed to implement.  This helped but just because the target was named the same thing it did not mean they worked the same way.

Long story short, we began to meet to create a shared standard.  During this long process we were introduced to Maven.  Ironically, Maven had accepted standards for many of the issues that we were trying address.  Maven was not just a standard for our company it was a standard for all Maven users.  New employees that were familiar with Maven had a good grasp of how we managed our projects.

Maven provided a standard that not only addressed our concerns as software developers.  It provided a standard solution that supported our corporate: audits, disaster recovery, tracability, and the list goes on.  We were trying to reinvent the wheel with Ant when the Maven community had already solved these problems.

Ant and Ivy are powerful ingredients for designing a custom build process.  Maven however is a powerful solution for building and managing software.  In our case we wanted a solution instead of the ingredients and tools to create our own solution.  Maven satisfied our needs and saved us significant time and money.

But It Downloads the Internet

I can’t tell you how many people have told me that they don’t like Maven because it “downloads the internet”. I find it ironic that many of them like Ivy.  I hate to break the news, but Ivy downloads the internet too. I’m not sure why this is a concern.  Is there a fear that Maven will fill up their hard drive?  Disk space is cheap.  The computer I am working on right now has 150GB of hard disk space and my Maven local repository is eating up 300MB of it.  This computer has pleanty of room for more of the internet.

I recall the first time that I tried to setup a new project without a dependency management tool.  I spent over a week trying to download the correct version of each JAR.  I was ready to take a vacation by the time I finished this ugly puzzle.  After using Maven and Ivy for managing my  dependencies I will never go back.  By the time I downloaded all the JARs that we needed, I felt like I had in fact downloaded the entire internet.

I love dependency management tools and they can have as much of my hard drive as they need.

Spring is an essential part of my technology stack. I cann’t image providing quality software that doesn’t leverage an IoC container. However, decoupling components requires some amount of configuration. Whether this is accomplished through annotations or XML, it’s fairly easy to mess up. Fixing these missing or incorrect configurations doesn’t take very long. The real question is how quickly can you identify these errors?

This question of how long, is a feedback loop question. Unfortunately many teams wait until they fire up the application server to see if their Spring context is wired correctly. This is too late.

One of our clients suffered from this very issue. Due to environmental constraints they could not run automated, in-container tests that would have identified misconfigured beans. After repeatedly committing stupid configuration mistakes, I decided that I would write a Spring wiring test. As I began to write this I encountered five problems.

Problem 1: Scope

The first problem that I encountered was that not all of my beans were being created when I loaded my context.

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration
public class SpringWiringTest{
 
     @Test
     public void testSomething(){
...

I quickly remembered that only beans with the default ’singleton’ scope will be loaded immediately. The rest of the bean scopes (’prototype’, ‘request’, and ’session’) will not be created until they are requested. In order to solve this I looped through all of the bean names and retrieved each bean from the context.

String[] names = context.getBeanDefinitionNames();
for(String name : names){
     context.getBean(name);
}

However, when I ran this I got the following error

java.lang.IllegalStateException: No Scope registered for scope 'request'

In order to correct this issue I added the following setup method.

@Before
public void testCaseSetUp(){
     context.getBeanFactory().registerScope("session", new SessionScope());
     context.getBeanFactory().registerScope("request", new RequestScope());
     MockHttpServletRequest request = new MockHttpServletRequest();
     ServletRequestAttributes attributes =
          new ServletRequestAttributes(request);
     RequestContextHolder.setRequestAttributes(attributes);
}

I threw in the session scope too just to be safe.

Problem 2: Abstract Bean Definitions

The second problem that I had to solve was requesting abstract beans.

org.springframework.beans.factory.BeanIsAbstractException: Error creating bean
with name 'testBean': Bean definition is abstract

In order to solve this issue I added a check to verify if a bean definition was abstract.

String[] names = context.getBeanDefinitionNames();
for(String name : names){
     BeanDefinition beanDefinition = context.getBeanDefinition(name);
     if(!beanDefinition.isAbstract()){
          context.getBean(name);
     }
}

Problem 3: Mock Beans

The third issue I found was environment specific beans. JNDI references are one type of environment specific bean.

<jee:jndi-lookup id="testBean" jndi-name="jdbc/test"/>

In order to solve this issue, I decided to create a test bootstrap context that imported all of the production contexts. This provided a place for me to override beans that I wanted to create for the test. I used Mockito to create mock beans in most situations.

<bean id="testBean" class="org.mockito.Mockito" factory-method="mock">
<constructor-arg value="com.something.Foo" />
</bean>

While this worked for most beans, I received errors when I wired up mock DataSources. Instead I used embedded databases to replace real DataSources.

<bean id="testDataSource"
class="org.springframework.jdbc.datasource.embedded.EmbeddedDatabaseFactoryBean"
p:databaseType="H2"
abstract="true"/>

Problem 4: Components

This fourth issue was harder to identify but equally problematic. I frequently wired up beans with the @Component annotation and failed to configure an ‘component-scan’ for those packages.

<context:component-scan base-package="com.sourceallies"/>

In other words I needed to reconcile the classes marked with the @Component annotation with the beans that were available in the Spring context.

ClassPathScanningCandidateComponentProvider scanner =
     new ClassPathScanningCandidateComponentProvider(true);
scanner.addIncludeFilter(new AnnotationTypeFilter(Component.class));
for (BeanDefinition bean : scanner.findCandidateComponents("com.something")){
      components.add(bean.getBeanClassName());
}

This will create a list of components found on the classpath under the specified base package. Reconciling this list with the beans loaded in the Spring context will identify any components that are not configured in Spring. This list came in handy for two reasons. First it identified any components that I needed to configure in Spring. Second it listed components that were provided in dependent jars. This list helped us become proactive instead of reactive.

Problem 5: Duplicate Bean Definitions

The fifth issue is duplicate bean definitions. This can occur when more than one bean has the same bean definition name. This can also occur when the same context is loaded multiple times. By default Spring allows the new bean definition to overwrite the previous one. This sounds annoying but harmless. On the contrary, Spring does not guarantee the loading order. Furthermore, each deployment environment’s classloader can load context files in a different order. The bottom line is that duplicate bean definitions can result in subtle and painful bugs.

While this issue was clear to me the solution was a bit more illusive. At first I tried to set the allowBeanDefinitionOverriding flag on org.springframework.beans.factory.support.DefaultListableBeanFactory. This throws an exception if the same bean definition is loaded multiple times. Case closed, right?

Unfortunately the solution was not this simple. Problem 3, Mock Beans, requires the creation of a test bootstrap context that overrides bean definitions. So the allowBeanDefinitionOverriding flag is out. After crying a little, I started exploring Spring. Long story short, I overrode the ‘protected void loadBeanDefinitions(DefaultListableBeanFactory beanFactory)’ method on org.springframework.context.support.ClassPathXmlApplicationContext and injected a delegating proxy.

@Override
protected void loadBeanDefinitions(DefaultListableBeanFactory beanFactory)
		throws BeansException, IOException {
	Enhancer enhancer = new Enhancer();
	enhancer.setSuperclass(DefaultListableBeanFactory.class);
	BeanohBeanFactoryMethodInterceptor callback = new BeanohBeanFactoryMethodInterceptor(
			beanFactory);
	callbacks.add(callback);
	enhancer.setCallback(callback);
	DefaultListableBeanFactory proxy = (DefaultListableBeanFactory) enhancer
			.create();
 
	super.loadBeanDefinitions(proxy);
}

I used ‘net.sf.cglib.proxy.Enhancer’ and ‘net.sf.cglib.proxy.MethodInterceptor’ to create a proxy. The trick was to delegate to the real ‘org.springframework.beans.factory.support.DefaultListableBeanFactory’ instance.

@Override
public Object intercept(Object object, Method method, Object[] args,
		MethodProxy methodProxy) throws Throwable {
	Method delegateMethod = delegateClass.getMethod(method.getName(),
			method.getParameterTypes());
	if ("registerBeanDefinition".equals(method.getName())) {
		if (beanDefinitionMap.containsKey(args[0])) {
			List definitions = beanDefinitionMap
					.get(args[0]);
			definitions.add((BeanDefinition) args[1]);
		} else {
			List beanDefinitions = new ArrayList();
			beanDefinitions.add((BeanDefinition) args[1]);
			beanDefinitionMap.put((String) args[0], beanDefinitions);
		}
	}
	return delegateMethod.invoke(delegate, args);
}

This passively collects bean definitions that are registered with the registerBeanDefinition method. This method takes two arguments: a String bean name (arg[0]) and a ‘org.springframework.beans.factory.config.BeanDefinition’ (arg[1]). This map of bean definitions can be inspected later to determine if beans were loaded multiple times.

Conclusions

This experience has lead our team to develop a complete, open source solution called Beanoh (pronounced \’beanˌō\). Simply download the jar or build the project with maven and start using it.

public class SomeTest extends BeanohTestCase {
 
	@Test
	public void testSomething() {
		assertContextLoading();
	}
}

For more information visit http://beanoh.org/overview.html.

In just a few short weeks this testing approach prevented our team from committing broken Spring configurations. Furthermore, we took time to evaluate the inherited components that we received through our project dependencies. This provided valuable insights into our dependency structure and our packaging strategy.

These wiring tests even gave us feedback as we refactored our spring contexts. We were able to simplify our context files without worrying that we would break something. We also identified unused and duplicate bean definitions. Without the quick feedback of this wiring test we would have committed broken changes that effected the whole team.

Automated tests help you manage code behavior rather than allowing code to drive your behavior. Download Beanoh today and take control of your Spring configuration.

For more information checkout our YouTube video tutorials.

public class MockitoTest {
 
   private EmailFactory emailFactory;
   private Notifier notifier;
   private Emailer emailer;
   private Email email;
 
   @Before
   public void setUp(){
      notifier = new Notifier();
 
      emailFactory = mock(EmailFactory.class);
      emailer = mock(Emailer.class);
      email = mock(Email.class);
 
      notifier.setEmailFactory(emailFactory);
      notifier.setEmailer(emailer);
   }
 
   @Test
   public void testSend(){
      when(emailFactory.create()).thenReturn(email);
 
      notifier.send();
 
      verify(emailFactory).create();
      verify(emailer).send(email);
      verifyNoMoreInteractions(emailFactory);
      verifyNoMoreInteractions(emailer);
   }
}

   public class Notifier{
      private EmailFactory emailFactory;
      private Emailer emailer;
 
      public void send(){
         Email email = emailFactory.create();
         emailer.send(email);
      }
 
      public void setEmailer(Emailer emailer) {
         this.emailer = emailer;
      }
 
      public void setEmailFactory(EmailFactory emailFactory) {
         this.emailFactory = emailFactory;
      }
   }

Here is the code using the new annotations.

@RunWith(MockitoJUnitRunner.class)
public class MockitoAnnotationsTest {
 
   @Mock private EmailFactory emailFactory;
   @Mock private Emailer emailer;
   @Mock private Email email;
   @InjectMocks private Notifier notifier = new Notifier();
 
   @Test
   public void testSend(){
      when(emailFactory.create()).thenReturn(email);
 
      notifier.send();
 
      verify(emailFactory).create();
      verify(emailer).send(email);
      verifyNoMoreInteractions(emailFactory);
      verifyNoMoreInteractions(emailer);
   }
}

   public class Notifier{
      private EmailFactory emailFactory;
      private Emailer emailer;
 
      public void send(){
         Email email = emailFactory.create();
         emailer.send(email);
      }
   }

This new annotation style reduced the number of lines of code by over 40%. The longer a test is the harder it is to understand. Reducing the amount of test code increases its clarity.

So how does it work? ‘@Mock’ is equivalent ‘Mockito.mock(Some.class)’. ‘@InjectMocks’ is equivalent to setting the mocks on the class under test. This annotation uses reflection to set properties so you do not have to add setters just for testing. Lastly, the combination of ‘@RunWith(MockitoJUnitRunner.class)’ and ‘@InjectMocks’ enables you to remove the ‘@Before’ method. This pair of annotations prepares the class under test before each test method.

I have been using mocks in tests for years and this is a great addition to this powerful framework.

public class ServiceExample1 {
	private FooDAO fooDAO;
	private BarDAO barDAO;
 
	public void searchForFooAndBar() {
		//
		// do some stuff
		//
 
		fooDAO.searchForFoo();
 
		//
		// do some more stuff
		// 
 
		barDAO.searchForBar();
 
		//
		// finish up doing stuff
		//
	}
 
	public void createANewFoo(Foo foo) {
		fooDAO.createFoo(foo);
	}
	public void createANewBar(Bar bar) {
		barDAO.createBar(bar);
	}
}

A couple of methods are defined, and they use two difference dao objects. Writing a test for the searchForFooAndBar method would currently involve providing alternative implementations for both the FooDAO and BarDAO objects. While this initially wouldn’t be too difficulty, it is easy to imagine how the number of dao dependencies could grow as the project goes on. It could also cause problems since we wouldn’t know which methods in the dao needed to be stubbed out or mocked for testing. I also worry that it would be too easy to test implementation instead of behavior. A test failure would be reported if the service changed which dao methods were called.

Another issue I’ve run into is not knowing which dao’s are involved in a method when writing the test. My initial thought was to not have the service object maintain references to the dao objects, but instead have each method require them as method parameters.

public class ServiceExample2 {
	public void searchForFooAndBar(FooDAO fooDAO, BarDAO barDAO) {
		//
		// do some stuff
		//
 
		fooDAO.searchForFoo();
 
		//
		// do some more stuff
		// 
 
		barDAO.searchForBar();
 
		//
		// finish up doing stuff
		//
	}
 
	public void createANewFoo(FooDAO fooDAO, Foo foo) {
		fooDAO.createFoo(foo);
	}
	public void createANewBar(BarDAO barDAO, Bar bar) {
		barDAO.createBar(bar);
	}
}

Looking over this code, I didn’t care for it from the start. Maybe if the service layer objects were finer grained. Instead of three methods in the service from our first example, maybe there should be 3 service classes.

	public void searchForFooAndBar() {
		//
		// do some stuff
		//
 
		fooDAO.searchForFoo();
 
		//
		// do some more stuff
		// 
 
		barDAO.searchForBar();
 
		//
		// finish up doing stuff
		//
	}

I think this would help fix the problem of having too many dao references, but I still wasn’t sure I liked the dependency on the dao’s themselves. That brought me to the final solution I thought of, which involves creating an interface for each method that defines the operations it requires to be provided.

public interface FooCreationAdapter {
	public void createFoo(Foo foo);
}
public interface BarCreationAdapter {
	public void createBar(Bar bar);
}
public interface SearchAdapter {
	public void searchForFoo();
	public void searchForBar();
}
public class Service {
	public void searchForFooAndBar(SearchAdapter searchAdapter) {
		//
		// do some stuff
		//
 
		searchAdapter.searchForFoo();
 
		//
		// do some more stuff
		// 
 
		searchAdapter.searchForBar();
 
		//
		// finish up doing stuff
		//
	}
 
	public void createANewFoo(FooCreationAdapter adapter, Foo foo) {
		adapter.createFoo(foo);
	}
	public void createANewBar(BarCreationAdapter adapter, Bar bar) {
		adapter.createBar(bar);
	}
}

While I feel this is the cleanest solution that would be the easiest to test, I really don’t think it is practical on a project level. Does anyone have a solution that has worked well for them?

• Setting Up
• Recording Tests
• Playing Back Tests
• Saving Test Cases
• Resuming Recording
• Saving Test Suites

All examples will use the sample site https://sites.google.com/site/example4selenium/.

Store Value

• There are two ways to store values.
• First, you can define custom variables



• Second you can use the drop-down ’storeText’ option.



• Enter a variable name.



• Variables can be used by simply surrounding the variable name with ‘${ }’



• Running this script will result in an insert of both variables separated with an ‘and’.

Debug

• To debug a script insert a breakpoint.



• Run the test case.



• The button resumes the execution of the script.
• The button steps through the test case one action at a time.

XPath

• Selenium IDE can navigate html using XPath. If you are not familiar with XPath there is a beginners tutorial at http://www.w3schools.com/xpath/default.asp.
• Instead of referring to the id of a target you can locate an element with XPath.



• You can verify your XPath by clicking the ‘Find’ button. The element will be highlighted in the browser with flashing neon green if it exists.
• If you want to select elements by position, you may want the following information. The traditional ‘//input[2]‘ does not work all the time in Selenium IDE. If you can not locate your target element by index, use the following syntax ‘//input/following::input’. This syntax specifies the location of an input that follows another input. This will result in the selection of the second input. Simply add another ‘/following::’ to get to the next matching element. Unfortunately this syntax is quite verbose.

Exporting Scripts

• Recorded scripts can be extracted into a number of programming languages.



• For this example lets export this test case as ‘JUnit 4 (Remote Control)’.
• Copy the resulting code into your favorite IDE.



• In order to get this to compile you will need to add the following dependencies to your classspath
• http://repo1.maven.org/maven2/junit/junit/4.8.2/junit-4.8.2.jar
• http://repo1.maven.org/maven2/org/seleniumhq/selenium/client-drivers/selenium-java-client-driver/1.0.1/selenium-java-client-driver-1.0.1.jar
• Download http://selenium.googlecode.com/files/selenium-server-standalone-2.0b2.jar
• Open a new terminal window and navigate to the directory where you downloaded the jar.
• run ‘java -jar selenium-server-standalone-2.0b2.jar’



• Run the JUnit test.



selenium-server-standalone-2.0b2.jar
• This test will open two new Firefox windows to execute the tests.



At first glance Selenium IDE may seem like just a QA tool for recording acceptance tests. While this may be true, this is a powerful tool for communicating defects, preparing for demos, and generating acceptance tests in your language of choice. Selenium IDE is a rich testing tool-set worth exploring.
]]> http://blogs.sourceallies.com/2011/04/selenium-ide-part-ii/feed/ 0 http://blogs.sourceallies.com/2010/08/would-you-start-mocking-me/ http://blogs.sourceallies.com/2010/08/would-you-start-mocking-me/#comments Thu, 05 Aug 2010 14:54:39 +0000 David Kessler http://blogs.sourceallies.com/?p=1545 One of the primary principles of unit testing is to test a small piece of functionality in isolation. In order to achieve this, mock objects are often necessary. Historically using mocks could be quite painful. After using several mock frameworks, my favorite by far is Mockito.

Tutorial

In this tutorial we will walk through examples of the most common features of Mockito. My sample project can be downloaded here.

Interfaces and Implementation

Some mocking frameworks only supported mocking interfaces. As a result our projects became bloated with useless interfaces that were only used for testing.  Mockito creates mock objects with interfaces or classes.


interface Person{
   List getChildren();
   Boolean isCitizen();
   Integer getAge();
   Map getSchedule();
   void haveChild();
}

class PersonImpl implements Person{
   public List getChildren() { return null; }
   public Boolean isCitizen() { return null; }
   public Integer getAge() { return null; }
   public Map getSchedule() { return null; }
   public void haveChild() { }
}

assertNotNull(Mockito.mock(Person.class));
assertNotNull(Mockito.mock(PersonImpl.class));

Default Values

Mockito provides stub implementations for all of the methods on the interface/class. It also provides several common sense defaults out of the box.

Person mockPerson = Mockito.mock(PersonImpl.class);
assertNotNull(mockPerson.getChildren());
assertEquals(0, mockPerson.getChildren().size());
assertFalse(mockPerson.isCitizen());
assertEquals(new Integer(0), mockPerson.getAge());
assertNotNull(mockPerson.getSchedule());

Mockito returns empty Lists and Maps to prevent NPE’s in your test code. It defaults to false for Boolean return values. By default Zero is returned for Integer, Long and Double. Notice that even though PersonImpl returns null for all of its methods the Mockito version returns reasonable default values.

Changing Behavior

Person mockPerson = mock(PersonImpl.class);
Mockito.when(mockPerson.getAge()).thenReturn(35);
assertEquals(new Integer(35), mockPerson.getAge());

Mockito.when() takes a mock and a method call that returns a value. Mockito’s thenReturn() method takes the return value that Mockito will provide to all matching calls. By default the method getAge() returns Zero, within Mockito, but now it returns 35. This ability to control behavior is the key to testing functionality in isolation.

Verifying Method Calls

Person mockPerson = Mockito.mock(PersonImpl.class);
mockPerson.getAge();
Mockito.verify(mockPerson).getAge();

Mockito.verify() takes a mock object and verifies that the following method is called.

Person mockPerson = Mockito.mock(PersonImpl.class);
mockPerson.getAge();
mockPerson.getAge();
Mockito.verify(mockPerson, Mockito.times(2)).getAge();

This is the same verify as before except a second parameter is passed to the verify() method telling it how many times the trailing method should be called.

Person mockPerson = Mockito.mock(PersonImpl.class);
mockPerson.getAge();
mockPerson.getAge();
Mockito.verify(mockPerson, Mockito.atLeastOnce()).getAge();

Sometimes it is not important how many times a method is called as long as it is called at least once. Mockito.atLeastOnce() method provides this flexibility.

No More Interactions

Person mockPerson = Mockito.mock(PersonImpl.class);
mockPerson.getAge();
Mockito.verify(mockPerson).getAge();
Mockito.verifyNoMoreInteractions(mockPerson);

Mockito.verifyNoMoreInteractions() ensures that no other methods have been called on the PersonImpl class. Since Mockito is very helpful in stubbing out all of the methods for a class or interface there is no control over which methods have been called. Only methods that have been explicitly verified are checked for specific calls.

Throw Exception

@Test(expected = RuntimeException.class)
public void testThenThrow(){
   Person mockPerson = Mockito.mock(PersonImpl.class);
   Mockito.when(mockPerson.getAge()).thenThrow(new RuntimeException("test exception"));
   mockPerson.getAge();
}

The thenThrow() method prepares the method defined in when() to throw an Exception. While I am not attempting to provide a tutorial on JUnit4 features, I feel it necessary to point out the Annotation verifies that a RuntimeException is thrown in the test.

@Test(expected = RuntimeException.class)
   public void testDoThrow(){
   Person mockPerson = Mockito.mock(PersonImpl.class);
   Mockito.doThrow(new RuntimeException("test exception")).when(mockPerson).haveChild();
   mockPerson.haveChild();
}

The doThrow() syntax is necessary to throw an Exception for a void method. The previous example threw an exception for Person.getAge() which is not a void method. In this example Person.haveChild() is void and requires this alternate syntax in order to compile.

TDD with Mockito

Let’s drive a small class that we will call Bouncer.  This class will check if a Person is old enough to drink.  First let’s write a test.

@Test
public void testCheckAgeOf_UnderAge(){
   Person mockPerson = Mockito.mock(PersonImpl.class);
   Mockito.when(mockPerson.getAge()).thenReturn(20);
   Bouncer bouncer = new Bouncer();
   assertFalse(bouncer.checkAgeOf(mockPerson));
}

Of coarse this does not even compile. We need to create a Bouncer class with the checkAgeOf() method. And here is the amazing class

class Bouncer{
   public boolean checkAgeOf(Person customer){
      return false;
   }
}

So why did I return false. Well the test does not require anything more than this to pass. TDD is about doing the simplest thing that works and then refactor the code. This is the simplest thing that works. Now let’s write another test.

@Test
public void testCheckAgeOf_OfAge(){
   Person mockPerson = Mockito.mock(PersonImpl.class);
   Mockito.when(mockPerson.getAge()).thenReturn(21);
   Bouncer bouncer = new Bouncer();
   assertTrue(bouncer.checkAgeOf(mockPerson));
}

Now we need real business logic in our method.

return customer.getAge() >= 21;

Green again. Now it is time to refactor. In this simple case I am not sure how to simplify the code. There are a few more tests that should be written. A test if getAge() returns null and if Person is null and other boundary cases. Since the focus of this article is on Mockito I will stop here.

Mockito is a powerful mocking framework that simplifies the creation and usage of mock objects. I encourage you to download my sample code and continue to explore the Mockito framework.

]]> http://blogs.sourceallies.com/2010/08/would-you-start-mocking-me/feed/ 3