I know that this concept is not really bleeding edge. The whole purpose of these two posts are to share an approach that I have used in the past to help me with my Test Driven Continuous development. I have not tried it with Hibernate or any other ORM. I have only used it with Spring JDBC Template and straight JDBC programing.

Architecture
First let me explain the requirements for your architecture to be able to support this type of mock tests.  A good architecture allows components to be unit tested.  If you need an entire environment stack to be able to unit test your code then your architecture is just a big mess.  Business logic layer needs to be separate from your data access.  Your interface layer needs to be seperate from your business logic layer.   This is true if you are doing a MVC web application or even a back end SOA implementation.  I’m not just talking about encapsulating these different layers in different classes, but also have these layers be loosely coupled.

1. Your Database queries should be externalized.  Do not hard code database queries or stored procedure calls.  I know that Hibernate allows you to annotate your code.  But can be a barrier to having your database access be portable.    However, you can get around this.  Configuration of your Database access should be loaded at run time.  Spring Beans do a nice job of handling this.  The Bean XML file gives you a great way to capture configuration information and load it at run time.  The Application Configuration allows you to load these files external to your actual business logic.
2. Your modules should be able to be run independent of any other infrastructure.  Make your modules Pojos.  Even if you plan to expose them as EJBs, MDBs or Web Services.  You can code your business logic as a Pojo.  This will allow simple clean unit tests that can run right out of the command line with no other application running.

Unit Test Implementation
So lets start with the Java code.. Below is an example of a simple Pojo that does some sort of business logic. (I left out the get/setters and import statements.)

public class BusinessPojo {

    private String sql;

    private DataSource dataSource;
    private JdbcTemplate jdbcTemplate;

    public String doSomething(String id) {
	SqlRowSet rowset = getJdbcTemplate().queryForRowSet(getSql(), new Object[] { id });

	return rowset.getString("Field1");
    }
}

This example defines 2 bean properties. The first is the SQL string that is executed, the second is the JDBC Datasource that the SQL is being executed against. The Pojo also uses the JDBC Template from the Spring framework. This is only to hide a lot of the messy JDBC code.

This is a very simple example. But it can easily be extended to take any number of input parameters and any number of returned values.
Also, this approach can be used with any framework that you can pass a JDBC Datasource and a SQL statement to.

Now let’s look at our test class:

package com.josephkampf.example;

import java.io.InputStream;
import java.net.URL;
import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.Statement;

import org.apache.commons.io.IOUtils;
import org.springframework.context.ApplicationContext;
import org.springframework.context.support.ClassPathXmlApplicationContext;
import org.testng.Assert;
import org.testng.annotations.BeforeClass;
import org.testng.annotations.Test;

/**
 * Unit test for the BusinessPojo.
 *

 *
 * @author Joseph Kampf (me@josephkampf.com)
 */
public class BusinessPojoTest {

    private ApplicationContext ctx;

    @BeforeClass
    public void setup() throws Exception {
	setUpHSQLDB("BusinessPojoTest", "/TestBusinessPojoSchemaSetup.sql");
	setUpHSQLDB("BusinessPojoTest", "/TestBusinessPojoDataSetup.sql");
	this.ctx = new ClassPathXmlApplicationContext(
		"spring-TestBusinessPojo.xml");
    }

    /**
     * Sets up the in-memory HSQLDB using the database name and initial SQL
     * script to populate the database.
     */
    public void setUpHSQLDB(String databaseName, String initSqlScript)
	    throws Exception {

	Class.forName("org.hsqldb.jdbcDriver");

	final URL url = this.getClass().getResource(initSqlScript);
	final String sql = IOUtils.toString((InputStream) url.getContent());

	final Connection connection = DriverManager.getConnection(
		"jdbc:hsqldb:mem:" + databaseName, "sa", "");
	final Statement s = connection.createStatement();
	s.execute(sql);

	s.close();
	connection.close();

    }

    @Test
    public void testProcess() throws Exception {
	BusinessPojo pojo = (BusinessPojo) this.ctx.getBean("pojo");
	Assert.assertEquals(pojo.doSomething("ID1"), "Expected");
    }
}

I use TestNG. I Like TestNG because it is annotation driven. Let’s take a look at what is going on in this test outside of actually testing the Pojo.

Take a look at the setUpHSQLDB method.  This method takes a name and looks up via a JDBC URL an in memory HSQLDB instance.  If the instance does not exist, it is created.  So we can always reference this instance again by using the same JDBC URL.  We will see this later when we create our BusinessPojo Test Spring context file.  The method also executes some SQL scripts in the in Memory Database.  The first sets up the table structures.  The second addes the data.  I’m not going to go into the details of what is in these scripts.  I’ll leave some examples as an attachment to this posting.  I refer you to the HSQLDB online documentation for details.  But what is happening here is the database is being set up in a known state in the same JVM that our unit test is running in.  No extra processes are required.

Note that we could take the setUpHSQLDB method and create a Test Fixture.  This is actually how I have implemented it in my code.  However I leave it all in one class for convenience.  Another option would be to add the setUpHSQLDB method in your base class. (Not the way I would go.)

Now lets connect our Pojo to the HSQLDB instance we have created in our Unit Test.  Below is the Spring Configuration that is loaded by the Unit Test.

spring config:
<beans>
 <bean id="pojo" class="com.josephkampf.example.BusinessPojo">
   <property name="dataSource">
     <ref bean="dbcpDataSource" />
   </property>
   <property name="sql">
     <value>SELECT f1 as Field1 from sample_table where id = ?</value>
   </property>
 </bean>

 <bean id="dbcpDataSource" destroy-method="close">
   <property name="driverClassName" value="org.hsqldb.jdbcDriver" />
   <property name="url" value="jdbc:hsqldb:mem:BusinessPojoTest" />
   <property name="username" value="sa" />
   <property name="password" value="" />
 </bean>
</beans>

Notice the url of the DataSource.  It has the form of jdbc:hsqldb:mem:BusinessPojoTest.  Notice that this is the same JDBC URL we used in our Unit Test to load up the database.  So when the Spring template obtains a connection, it will be obtaining a connection to the in memory HSQLDB instance.

Non-Unit Test Implementation
Now when you actually go to a non-unit test environment, you will need a diffrent Spring Application Context file.  Below is an example of an Application Context that defines this Pojo to connect to an Oracle Database. This is an example of what you might use in an environment that is beyond Unit test.(Integration, QA, Stage, Production, etc.)

<beans>
  <bean id="processor" class="com.josephkampf.example.BusinessPojo">
    <property name="dataSource">
      <ref bean="oracleDataSource" />
    </property>
    <property name="sql">
      <value>SELECT oracleField1 as Field1 from oracle_sample_table where id = ?</value>
    </property>
  </bean>

  <bean id="oracleDataSource">
    <!-- Insert Oracle datasource configuration here. -->
  </bean>
</beans>

Notice that the SQL has changed to conform to the Oracle database. All that matters is that both SQL values have the same structure for the Select clause have the same fields by name and the Where clause have the same number and order of the bind variables.

Mock Data Testing is an important step to delivering on a Test driven and continuous development effort. You really should not need a running external database to be able to run your Unit Tests. Your Unit Tests should be using a known set of data so that you can do meaningful Assertions in your Unit Test code. You also need to be able to spend less time coding that Mock Data. Using SQL to define this test data is a more intuitive and faster mechanism than other solutions. Spring allows you to separate your concerns so that you can create testable units.

I expect this to be the first of threetwo posts on this topic. First I’ll explain the problem that this approach solves. In the second post I’ll explain the approach. In the last post I’ll discuss some additional concerns such as having to deal with Stored Procedures.

For an explanation of Mock Object Testing see Wikipedia who actually does a nice job of explaining what it is all about.

The reason that Mock Testing is important is that Unit tests should be repeatable and automated. Developers should be able to check out code and unit tests from a source control system and be able to run a script or command that builds and tests. Unit tests shouldn’t need to rely on databases, or other external dependencies. Plus the state of a database can become unknown. When doing test driven development you need to be able to run a test over and over again. You can’t worry about the data already being in the database.

I was first introduced to the concept of Mock Testing by my old friend and colleague Howard Spector during my time at FirstUSA/Bank One Card Services.  It was my first experience with Test Driven Development.  Back in those days we had our own Data Services Framework.  This was a framework that provided an interface that was an abstraction over Relational Database.

Because this framework was an interface we could use test implementations that would return mock data objects.  However it always felt clumsy.  Creating the test data was a manual time consuming task.  There were 2 ways to create the Mock Data objects. 

The first way is to hand code a factory that would set the values of the properties of data objects.

public List getDataPojos(String arg){
  List returnList = new LinkedList();

  DataPojo dataPojo1 = new DataPojo();
  dataPojo1.setString1("String 11");
  dataPojo1.setString2("String 12");
  returnList.add(dataPojo1);

  DataPojo dataPojo2 = new DataPojo();
  dataPojo2.setString1("String 21");
  dataPojo2.setString2("String 22");
  returnList.add(dataPojo2);

  return returnList;
}

Another option that has a little bit more flexibility is to parse a properties file or XML file.

With either approach there needs to be some sort of translation from the source to the Mock Data object that is essentially throw away code. This will cause the developer to spend more time writing code to create Mock Data objects than writing the actual tests or even the actual code.

In my next post I’ll detail how we can solve the issue of spending too much time creating Mock Data objects.

Has that changed at all?  Right now we here in the United States are facing unemployment like we have not seen since the great depression.  I feel lucky that I currently have skills that are in demand.  A lot of people I know are not that lucky.  But I wonder for even the software developers out there has this economy made you think twice about pursuing new opportunities.

I had a hard time making this decision about a year ago.  The market had already started it’s down turn.  I wasn’t getting assignments that were a fit for my skills and location.  I spent a great deal of time in 2008 sitting on the bench.  Granted I got paid.  But I was a draw on the company’s bottom line.  For me there was nothing worse than having to report to the office every day (even if it was an abbreviated day.) and not have work that someone counted on me producing.  I was given some bench assignments.  But there was little collaboration.  I’m one to thrive on the back and forth of the work day.

I loved my time with that old consulting company.  I had great friends there.  I had gone through some tough times while I was there in my personal life.  They were always great to me.  I felt like I was well respected.  But it was time to leave.  I have yet to regret a decision I have made in my career.  I don’t regret leaving.  Although I would not be opposed to working with them again in the future.

So what are the types of things that you look for when you decide to move on?

• Better Pay
• More exciting work
• Change in management
• Change in direction of your company
• More responsibility
• Less responsibility
• Work environment

For me it was “More exciting work” and “different work environment.”

Right now I am working as a Contractor.  I see myself having to make these decisions a lot more in the future.  I also see these decisions being made for me as well.  My original contract was set to expire at the end of the year.  I’ve since been extended until April 30th.  I am grateful that I will have a contract through the lean months of November, December, January and start of February.

I’ve imported my posting from Joe’s JavaOne blog that was hosted on Blogger (or BlogSpot as it use to be called.)

This Blog is going to be the place where I am going to be posting my thoughts on Java, Technology and Business in general.

I hope you enjoy it.

First two are very useful and I can see using them right away. First they showed off a Visual VM tool. This tool pulls together all of the metrics about a JVM into one place. This includes Heap Analysis, and Garbage Collection. It also has an API that allows you to write your own modules.

The next innovation was put on by Tor Norbye of the Java Posse. It was the Javascript integration with NetBeans. It had code complete, and an interactive debugging in Firefox. I think it might be time to give NetBeans a real look.

There was project Darkstar which is like an application server for online games. Seems to have some really neat stuff and allow game developers to concentrate on developing games and not the plumbing that is nessisary to run an online game.

Sentilla is a company that makes JavaME sensors. I wrote earlier in the week about how they have these sensors all over the convention hall tracking the movement of people. THey did an interesgting demo by putting these sensors into beach balls, and having the crowd hit the beach balls around. They displayed the location of the beach ball on the screen. They used some of these Sentilla sensors that used signal strength to calculate the position.

Probably the most interesting piece of JavaME was the Pulse Live Scribe smart pen. This is a pen that can record audio while you write and then replay it, store it on the computer, etc. The pen also allows the development of applications that can run right in the pen. They demoed a very cool piano application. The user of the pen, drew the keys on paper, and then was able to play notes on the piano he drew. God I wish I had one of these while I was in college.

There were also a couple of other demos having to do with Real Time Java. Some industrial applications, an entry for the DARPA XPrize (Tommy Jr. the car was called.), and an application that helped render data from Mars to help them track down water on Mars.

Subject: URGENT! PUBLIC HEALTH ADVISORY FROM JAVAONE TEAM

The JavaOne conference team has been notified by the San Francisco Department of Public Health about an identified outbreak of a virus in the San Francisco area. Testing is still underway to identify the specific virus in question, but they believe it to be the Norovirus, a common cause of the “stomach flu”, which can cause temporary flu-like symptoms for up to 48 hours. Part of the San Francisco area impacted includes the Moscone Center, the site of the JavaOne conference which is being held this week. We are working with the appropriate San Francisco Department of Public Health and Moscone representatives to mitigate the impact this will have on the conference and steps are being taken overnight to disinfect the facility. We have not received any indication that the show should end early, so will have the full schedule of events on Friday as planned. We hope to see you then.

Please see the attached notification from the Department of Public Health.

For further information, as well as Frequently Asked Questions related to the Norovirus, please visit the San Francisco Department of Public Health website at http://sfcdcp.org/norovirus.cfm

Both of my former Colleagues who are here at Java One with me both got this bug. I’v e been ok. The only ill effects I have felt have been self inflicted. I did notice that the lines in the mens rooms between sessions was very long.

The current Garbage Collector is called CMS. (I have no idea what it stands for.) The new Garbage Collector G1, is a generational Garbage Collector much like CMS. However instead of the physical seperations between the Young and Old generations, it allocates 1 meg blocks of memory and designates on the fly the purpose of that block (Old or young.)

I’m suppose to do a presentation for NUGS on tuning Garbage Collectors next week. I’m going to try to squeeze in some info on this new Garbage Collector, and even take a look at how the JRocket Garbage Collector work.

Here is the photo:

The owner of the restaurant asked me to email him the photo so he can put it on the wall. So now I am photographer that has been published in San Francisco.

It is important to put the database into a well known state before starting the tests.

Could be tested using JUnit, but there is a lot of code. Lots of code to initialize the DB, and then a lot of code to verify the results.

DBUnit is a framework for doing this type of coding. There is representations of what the data should be when the test starts, and representation of what the data should look like after the test.

This looks really promising for those types of tests that update data. It would also have excellent application to more than just Unit tests, but also automated testing of any kind of data.