Introduction
Unit Testing has become one of the corner-stones of good software development (it has been such for quite a long time actually). However writing a Unit Test that interacts with database code (at any level) can be very challenging. The main problem being: your data should be in a “known” state when the Unit Test starts running. In the past many approaches to this problem have been taken, such as: using an in-memory database; or DbUnit. Each approach has it’s up-sides and it’s down-sides (I won’t be going into them here).
To help your unit testing along EoD SQL is growing it’s own mocking extension (currently only in Subversion however). The EoD-Mock project allows you to build mock implementations of your database connection code without any external configuration. Thats right: no dependency injection; no JNDI; no factories; nothing!
How does it work?
If the EoD-Mock JAR file is on the class-path, EoD SQL will automatically look for mock implementations of your Query interfaces instead of generating a real implementation. For example, take a simple UserQuery interface:
public interface UserQuery extends BaseQuery {
@Select("SELECT * FROM users WHERE email = ?1")
User selectByEmail(String email);
@Update(sql = "INSERT INTO users (email, username, birth_date) "
+ "VALUES(?{1.email}, ?{1.username}, ?{1.birthDate})",
keys = GeneratedKeys.RETURNED_KEYS_FIRST_COLUMN)
User insert(User user);
@Select("SELECT * FROM users")
DataSet<User> selectUsers();
}
To create a Mock of this interface using EoD-Mock all you need to do is write an implementation in the same package:
public class UserQueryMock extends AbstractMockQuery implements UserQuery {
private final List<User> users = new ArrayList<User>();
public UserQueryMock() {
insert(new User("joe.bloggs@nowhere.com", "Joe Bloggs", new Date(83, 3, 6)));
insert(new User("jeff@jeffswebsite.com", "Jeff Site", new Date(76, 8, 23)));
insert(new User("logan@murkmurk.com", "Logan Sleep", new Date(90, 4, 1)));
}
public User selectByEmail(final String email) {
for(final User user : users) {
if(user.getEmail().equals(email)) {
return user;
}
}
return null;
}
public User insert(final User user) {
final long id = users.size();
final User clonedUser = new User(
user.getEmail(),
user.getUsername(),
user.getBirthDate());
clonedUser.setId(id);
users.add(clonedUser);
final User idUser = new User(null, null, null);
idUser.setId(id);
return idUser;
}
public DataSet<User> selectUsers() {
return new MockDataSet<User>(users, false, true);
}
}
Yup, it’s really as simple as that. Now if you ask EoD-SQL for an instance of UserQuery (ie: QueryTool.getQuery(UserQuery.class)): instead of generating an implementation, it will create an instance of UserQueryMock and return that.
How much does eod-mock take care of?
- EoD-Mock will self-register as a QueryFactory with EoDSQL (but only under Java 6 and higher) if it’s on the classpath
- A “default” DataSource is provided automatically. The provided implementation throws exceptions instead of providing database access
- An AbstractMockQuery class is provided to take care of the methods declared in BaseQuery
- A MockDataSet is provided, and will attempt to behave like a real DataSet object
- QueryTool.getQuery will automatically return mocked query objects, meaning: no changes to your data-access layer
Current State
EoD-Mock is currently only available in the Subversion repository, but will be included in the next release of EoD SQL. There is no support currently for the DataIterator class, but that will no-doubt come very soon.
Lemnik Technology Blog 