First, I gave the task to a colleague. He came up with something that checked each file, and returned a list of the bad ones. It then asserted that the nonWellFormed list had a zero length. Which is great and all, but didn’t tell you which file was broken, nor why.

What I really wanted to do was have a single test per file, so it could display the errors correctly. This seemed like an easy thing to do… Until I tried it. This is what I eventually arrived at:

  class WellFormedTest extends TestCase {
    public static Test suite() {
        final TestSuite suite = new TestSuite(WellFormedTest.class.getCanonicalName());
        // Stupid bloody Java regexes have to match from the beginning of the
        // string.
        Pattern p = Pattern.compile(".*\\.(xml|xslt|xconf|xmap)$");
        FindFiles ff = new FindFiles(p) {
            protected void processFile(final File file) {
                suite.addTest(new WellFormedTest(file));
            }
        };
        ff.search("web");
        return suite;
    }

    private File file;

    public WellFormedTest(File file) {
      super("Well-Formed? " + file.toString());
      this.file = file;
    }

    protected void runTest() throws Throwable {
      XmlValidator validator = new XmlValidator();
      String result = validator.isWellFormed(file);
      assertEquals(file.toString(), null, result);
    }
  }

• FindFiles is a utility class to walk a directory tree. Tell me again why Java doesn’t have something this basic in it’s vast class libraries?
• You have to call super("blah") in your constructor to name each test sensibly.
• But if you do this, you have to override runTest() in order for things to actually work. The usual mechanism for determining which tests to run doesn’t work if you supply a custom name. This took forever to work out and required delving into the JUnit source. Halleluljah for Open Source.
  • As part of prodding around in the debugger, I noticed that JUnit creates a new TestCase object for each test in the class. So it’s OK to just do one thing in runTest(), as that’s all that’s going to happen anyway.
• XmlValidator is another custom helper class. It just parses the file and returns a String containing the error (or null).
• Yes, this is JUnit 3.8. I know I need to migrate to JUnit 4. That’s a battle for another day, dependent on upgrading ant first.

Originally, I tried to get the test done inside a nested anonymous subclass of TestCase, but there’s no constructor there, so that doesn’t work too well. Plus it bumps the ugliness of the source another level.

The end result works quite well and provides a useful example for doing dynamic tests with JUnit.

  public class Ls {
    public static void main(String argh_my_aching_fingers[]) {
      // ...
    }
  }

Glad to know I’m not the only one.

However, there does appear to be a workaround. Add this to each class:

  public static junit.framework.Test suite() {
    return new junit.framework.JUnit4TestAdapter(SimpleTest.class);
  }

However, that’s now causing my tests to fail with NullPointerExceptions inside HttpUnit. Yet they work fine in Eclipse. Wonder what I’m doing wrong?

Update: It’s entirely my own fault—my ant task was forgetting to copy over non-java artifacts into the classpath. So adding suite() makes things work just fine.

This is the simplest test case.

  import org.junit.Assert;
  import org.junit.Before;
  import org.junit.Test;

  public class MyTest {
    @Before
    public void setUp() throws Exception {
      // ...
    }

    @Test
    public void alwaysTrue() {
      Assert.assertTrue(true);
    }
  }

You can make this slightly nicer by using static imports for the assertions. I didn’t because I wanted eclipse to complete them and I couldn’t auto-discover them as easily. I’ll probably switch shortly.

The annotations are also used for stating which exceptions you wish to catch.

All in all, I’m quite impressed. It’s about as simple as it gets in Java.

I suppose I could get around it by writing a build.sh which sets the CLASSPATH correctly, but I thought ant was supposed to avoid all that?