Symphonious

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.

public void testSetNativeLookAndFeel() {
    _editor.setNativeLookAndFeel();
    assertEquals(UIManager.getSystemLookAndFeelClassName(),
        UIManager.getLookAndFeel().getClass().getName());
}

public void testErrorWhileSettingNativeLookAndFeel() {
    System.setProperty("swing.systemlaf", "foobar");
    _editor.setNativeLookAndFeel();
    // Check the exception was handled correctly.
}

There's going to be very little value in the test because the usual error handling will be to just log the exception and keep going, but if you prefer to keep tests at 100% coverage to avoid the slippery slope, it will cover the code and ensure it does what you want.

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. In some cases the tests may not be able to cover everything but should give you at least a foundation to work from. Just make sure that as you write the tests you note down the things you couldn’t write an automated test to cover and make sure you do add a test for them after your refactoring.

See also: Refactoring Without Tests

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).

Integration tests are essentially to success - they make sure that your atomic tests are testing the right things and that the end result you get is what you actually want. It's extremely beneficial to write acceptance and integration tests before you start writing atomic tests (see: Acceptance Test Driven Development). The design phase however has to be done with atomic tests if you want to encourage decoupling of code.

It's definitely enlightening to look back at code that has been created using integration testing instead of atomic testing and see how much more complex it looks.

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?

Oh and the documentation is abysmal. Even the documentation that's there is hard to find because it's just been dumped on a Wiki instead of thoughtfully laid out.

Oh well, mostly it appears to be working anyway and it means I can turn XML-RPC back on and use an external blog editor again.

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. You can pick these people because they set their HTML editors to insert a BR on enter instead of inserting a new paragraph. The end result looks right in all browsers but destroys the semantic structure of the document. I imagine it would be much harder to navigate through the document using a screen reader too, since skipping paragraphs seems like a nice way to skim. The problem people most often run into with this approach is that their editor still treats the whole big block as a paragraph, so when they apply a heading style the entire document becomes a H1 tag with a bunch of BRs.

The other way that people try is to use DIV instead of P, this probably works better with screen readers, but has the same problem with the HTML not meaning what the user expects it to mean. In this case, it manifests as editors that wind up inserting a H1 inside the DIV instead of converting the DIV to a H1. Even worse, the editor may insert P tags on enter instead of creating a new DIV. The worst of all is when the editor inserts BRs on enter because there's no paragraph tags to split. It all winds up getting very messy.

Fortunately, there's a very simple solution to the entire problem that will let you just use P tags instead of all these nasty work arounds. In your stylesheet, just add:

p {
  margin-top: 0;
  margin-bottom: 0;
}

No more spacing above and below the paragraphs. You have in fact done the exact equivalent of going into paragraph formatting and setting space before and after to 0. The semantic structure of the HTML is preserved, editors will know what to do with the HTML without needing to be configured and fought with, your HTML markup will be cleaner and easier to read and your content will be more accessible.

If you can't control the stylesheet for the document, you can put the CSS inline:

<p style="margin-top: 0; margin-bottom: 0;">Paragraph content.</p>

It is important to set both margin-top and margin-bottom to 0, while every browser I've seen defaults to putting space between paragraphs, some browsers apply it to the top, some to the bottom and some apply it to both. Setting top and bottom to 0 guarantees it will look like you want.

Oh and don't worry, most editors will let you press shift-enter to insert a BR when you really do have a paragraph that needs a hard line break.