sealisland.net

The Pursuit of Coverage...

noreply@blogger.com (KPSeal) — Thu, 25 Sep 2008 21:01:00 +0000

I've never really got on fully with unit testing for various reasons. Most developers I've worked with know how to write a test but don't seem to know what to test, locking in behaviours that need not be fixed, are extraneous or are undesirable. I'm by no means an exception to this!

The pursuit of coverage seems to lead to smaller and smaller test cases: TestEveryMethod feels like an anti-pattern to me. The definition of a unit as being the smallest "testable" part of an application is very weak. After all, we choose what to make testable as part of our design process. Are units defined by the design or the design by the resolution of units desired? Testing is simply one of the forces on our design and needs to be weighed in the balance like everything else. The benefits can be vast, but the drawbacks can also be significant.

Coverage reports have always made me slightly suspicious. Their usage is usually tempered with the caveat to "focus on the more critical sections of code: business logic etc." From a process standpoint it would seem prudent to get the coverage report to do the focusing automatically. Coverage also tends to be self-fulfilling; I certainly can't resist the temptation to push up line or branch coverage in a spare moment. The naive approach to doing this is to write a test case, thereby succumbing to the force of the testing on the design without any consideration for the other forces.

I've recently found that a coverage report from a functional test points you in another direction: to remove the untested code. For example, a typical JavaBean contains as much code for equals, hashCode and toString as setters and getters. Surprisingly few domain objects have equality or hash characteristics that matter to anything other than unit tests (ie, for verifying return values). A functional test won't use it, but removing it might break a unit test which relies on it; is this investment in code with no business value paid off by the benefits of testing? Obviously the answer depends on the context, but knowing that you have a method (or behaviour) that exists solely or largely to support testing rather than the requirements changes the forces on the design. Introspection-based implementations or comparators that form part of your test support classes rather than polluting your domain model are possibilities. Furthermore, the notion of equality (and hence hash values too) is context-specific; a unit test probably wants to check every property whereas in the context of the application comparing a unique identifier might be sufficient. Has the unit test polluted the design?

ITunes 8 - a work of genius?

noreply@blogger.com (KPSeal) — Tue, 09 Sep 2008 20:36:00 +0000

I was quite excited by the prospect of a new version of iTunes. I've been listening to music using my MacBook and Airtunes quite a lot of late so any improvements might be welcome. A new visualiser might be a fun distraction but the new Genius feature ought to help me filter out some of the less appealing albums in the library I share with my wife and son.

After kicking the tyres a bit it turns out that the new browsing features are definitely welcome - I was finding the cover flow view a bit awkward so having the tiled album view is handy. The new visualiser is pretty cool too, although some of the modes are clearly causing my low-end MB to struggle. Only time will tell whether it replaces Jellyfish as my fan botherer of choice but it's a nifty addition nonetheless.

As for Genius, I'll reserve final judgment on it until a bit later. Perhaps it'll take a while for iTunes to collate more usage data to be totally reliable? The lists I generated from it were generally close, but quite what "Genius" figured that Belinda Carlisle's "Circle in the Sand" belonged in a list based on Iron Maiden's "22 Acacia Avenue" is anyone's guess! Still, it's better than random or genre-based playlists and the occasional bit of serendipity could be nice. Perhaps it's reminding me that the Belinda album in question is also mine, after all?!

The Quietly Failing INSERT (or Whyohwhyohwhybase)

noreply@blogger.com (KPSeal) — Mon, 08 Sep 2008 14:31:00 +0000

Interesting problem uncovered today. We're using a fairly standard Spring JDBC template to insert some entities into Sybase:


int rows = jdbcTemplate.update("INSERT INTO my_table ...", values, types);

The number of rows inserted into the database table was not the same as the number of times the SQL was executed. No exceptions thrown, so no key or constraint violations.

It turns out that an insert of a value into a NUMERIC column which requires rounding fails silently on Sybase. For example, inserting 1.23456 into a NUMERIC(6, 4) column would fail but not throw any corresponding SQLException from JDBC.

Aside from ensuring the column type is precise enough and rounding BigDecimals before insertion, we've now coded defensively by actually verifying that an insert returns a value of 1:


if(rows == 0) {
  log.error("Unable to insert entity", ...);
}

Will I be able to resist the urge to check the return value from inserts in the future?

Finally got some hosting!

noreply@blogger.com (KPSeal) — Fri, 05 Sep 2008 16:07:00 +0000

After years of putting things off I've finally bothered to get a hosting package and point blogger.com at it.

Fingers crossed the domain name actually serves something up in a few minutes (as promised)!