Setting the system look and feel is a common task in applications and if you’re shooting for 100% test coverage, it’s problematic because it uses two static methods and has checked exceptions. Typically you have something like: void setNativeLookAndFeel() {    try {        UIManager.setLookAndFeel(        UIManager.getSystemLookAndFeelClassName());    } catch (Exception e) {        // Handle exception somehow.     } } As far as I know, there’s no way to write a test that doesn’t also exercise UIManager, so we’ll have to live with that, but we can test that the UI is set and the exception handled.

When you work with legacy code, it’s easy to fall into the trap of thinking that because you can’t atomically test it that you should refactor it and add tests. This is a mistake. You should write integration tests, then refactor it, then write atomic tests. Even when the refactoring seems simple, it’s still possible to stuff it up. Most code can have integration tests written for it, even when it wasn’t designed for testing.

The basic principle of TDD is that you write the test first and then write the code required to make that test pass. There’s more to it though if you expect to see all the benefits. If you drive your development from integration tests instead of atomic tests, you’ll wind up with highly coupled code again and because it grows gradually without up-front planning, it’s often harder to understand. If however, you drive your development by atomic tests, you are very strongly encouraged to decouple your code whenever possible because mocking out dependencies is so annoying and time consuming (plus the more you have to mock, the more brittle your tests tend to be).

I’ve finally gotten around to upgrading to WordPress 2. Mostly I held off because it was going to destroy my integration of EditLive! for Java (I didn’t bother learning about plugins, just edited the WordPress source code). This time around I’ve integrated ELJ via a plugin, but the plugin API doesn’t make it particularly simple. Why is there no action for generating the editor? Shouldn’t it have been reasonably obvious that people might want alternative editors?

There seems to be a great demand for HTML documents that don’t include white-space between paragraphs – similar to going into the paragraph formatting in Word and setting space before and space after to zero. This is very simple to achieve in HTML, but people just keep coming up with strange ways to attempt to achieve it. The most common way people try to get around the problem is by putting their entire document in one P tag and using BRs.

Useful tool for writing performance tests: Japex. Must remember to use that when we do our next round of profiling. Doug’s suggestion is that once we identify a bottleneck in the code, we write a performance test for it with Japex then try to optimize it until we reach the desired performance level. I’m not sure that our codebase is likely to see performance regressions in the same area again (I can’t ever recall having to reoptimize the same section of code), however having the test would be able to quantify how much of a performance benefit we get which would be a useful metric to know.

As part of planning our wedding next year, the lovely Janet and I have begun looking into photographers. It seems that at least some photographers apply the same dodgy lock-in practices as software companies do by holding onto the copyright of the pictures they take at your wedding and forcing you to go back to them for reprints. Apart from the fact that I’m somewhat uncomfortable with anyone owning the photographic memories of our wedding, the terms and conditions from one particular photographer are just ridiculous.

There is one major problem with test driven development – it makes it easy to get lost. When you don’t use TDD, you tend to run your application a whole lot to see what effect your latest code has made. With test driven development, you run your atomic tests a whole lot instead. The trouble is, if your unit tests are taking you in the wrong direction, it can be a long time before you find out.

I’ve been developing some custom views (javax.swing.text.View subclasses) in the last few days. These are right up the alley of GUI code that people tend to find difficult to test but I’ve been pushing forward with test driven development with a fair bit of success. The main approach I’ve been using is to mock out pretty much everything the view interacts with and test it’s logic more than it’s actual rendering.

Note to self: I must read up on Andy Roberts’ Delta Web proposal and get involved. It looks decidedly useful.

Most code bases have some kind of code debt associated with them, legacy code bases tend to have lots of code debt. The good news is, paying back that code debt isn’t a complete time sink – it has definite advantages too. Obviously, reducing code debt tends to make the team go faster, but it also tends to fix bugs. Quite often where there is debt, there is not just a lack of maintainability but actual bugs that are frustrating your users.

In an effort to reduce the ridiculous amount of time wasted on April Fools day, the USA will be separated from Canada and Mexico and towed westward across the international date line, thus making April fools day start first in the US and letting them post all the pointless drivel to the internet prior to the rest of the world waking up. With the current location of the US, Australians have to put up not only with 24 hours of their own stupid April fools jokes but with an extra 12-16 hours of the US’s jokes the next morning.