Automated testing

TDD – Avoid coupling implementation to test code

Leave a comment

The old “classicist” vs “mockist” debate

I have recently read Martin Fowler’s “Mocks aren’t stubs” article, of which a big part is about the (what he calls) “classicist” vs “mockist” approaches to testing and TDD.

In short, it comes down to this:

  1. The “classicist” prefers to write mini-integration tests that test a group of classes together without resorting to test doubles (mocks, stubs and the like) for most things unless to replace calls to an external system such as a database or web service.
  2. The “mockist” prefers to test units (mostly classes) in complete isolation, replacing collaborators with test doubles.

Which side to choose when doing TDD

I personally lean more towards the “classicist” approach for the following reasons:

  1. The “mockist” approach often tightly couples the implementation to the test and tends to make the test brittle: changes to the code will often mean changes to the test even if they don’t change the behaviour in the bigger picture of collaborating classes. And when that happens, the test has had no use since it was meant to confirm that a refactoring was done correctly without introducing bugs.
  2. One of the main goals of writing automated tests is to catch bugs. My experience tells me that bugs usually occur when different parts are put together and would often not get caught by testing the parts in isolation.
  3. Another goal is to provide documentation. Indeed, by looking at test code, it should be clear what the expected result of a piece of code is, i.e. what business value it provides. It does not have to be clear what collaborators are called in what order: that should be clear when looking at the code under test.

The first one, the tight coupling, is the most important to me. In my opinion, while refactoring it often degrades the red bar in the test report to nothing more than a glorified “Are you sure?” type popup message. And the answer would be “No, I’m not”, since I wasn’t expecting the test to be failing since my refactoring should not have any effect on the end result.

In this recent talk by Ian Cooper called “TDD, where did it all go wrong”, he explains very well why this coupling is so bad and how it is against the original spirit of TDD, as designed by Kent Beck.

Programming

TimeZone handling with MyBatis and PostgreSQL

Leave a comment

The problem

I don’t like time zones. If it were my call, they wouldn’t exist and UTC would be used everywhere. Needless to say, I like Daylight Savings Time even less. These things just cause headaches for programmers. But until I become president of Planet Earth, we’ll probably have to deal with them.

The easiest way is to do all backend processing and storage in UTC and only convert to a local time zone in the UI layer. This requires you to set the database’s time zone to UTC:

ALTER DATABASE mydb SET TIMEZONE='UTC';

So I was using MyBatis to insert and retrieve date and time information in a PostgreSQL database.  Even though my database was set to UTC and a java.util.Date is by definition UTC, the JDBC driver seemed to interpret the time with the wrong TimeZone.

Even setting the default java TimeZone to UTC using
TimeZone.setDefault(TimeZone.getTimeZone("UTC"));
didn’t completely resolve my issues. I don’t really know why not, but doing that isn’t such a good idea anyway.

The solution

Fortunately, MyBatis allows you to define your own type handler to get complete control over how the java type is converted, and JDBC allows to specify a Calendar object whose TimeZone should be used to convert the date/time information.

So the solution is simple: write a type handler for java.util.Date that uses a Calendar object with time zone UTC to store/retrieve a timestamp.

public class UTCDateTypeHandler implements TypeHandler<Date> {

    @Override
    public void setParameter(final PreparedStatement ps, final int i, final Date date, final JdbcType jdbcType) throws SQLException {
        if (date == null) {
            ps.setNull(i, jdbcType.TYPE_CODE);
        }
        else {
            Timestamp timestamp = new Timestamp(date.getTime());
            ps.setTimestamp(i, timestamp, getUTCCalendar());
        }
    }

    @Override
    public Date getResult(final ResultSet rs, final String columnName) throws SQLException {
        return rs.getTimestamp(columnName, getUTCCalendar());
    }

    @Override
    public Date getResult(final ResultSet rs, final int columnIndex) throws SQLException {
        return rs.getTimestamp(columnIndex, getUTCCalendar());
    }

    @Override
    public Date getResult(final CallableStatement cs, final int columnIndex) throws SQLException {
        return cs.getTimestamp(columnIndex, getUTCCalendar());
    }

    private static Calendar getUTCCalendar() {
        return Calendar.getInstance(TimeZone.getTimeZone("UTC"));
    }
}

Then in the MyBatis configuration, register the type handler for java.util.Date and whatever SQL type you are using:

  <typeHandlers>
    ...
    <typeHandler handler="be.mediagenda.mybatis.UTCDateTypeHandler" javaType="java.util.Date" jdbcType="DATE"/>
    ...
  </typeHandlers>

Random thoughts to some degree related to Java development