I wanted to share some interesting things that myself and my colleague Emil “Bud” Lefkof have done recently in the realm of Mock Testing using Spring and HSQLDB.
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.