Is Technical Debt still a mess?

Robert Martin just published a note on Technical Debt, and his definitions leaves me a bit confused. Uncle Bob describes Technical Debt as the result of a conscious business decision.

As a simple example, your initial website design may need to be frames based because you don’t have time to build an Ajax framework.

I usually use the term to describe the result of developers (more or less conscious) decisions to deliver features that are not really done. When a team is delivering features lacking automated tests, proper refactoring, documentation, or whatever is (or should be) incorporated in their Definition of Done, a debt occurs, because these features though formally delivered still require more work. Perhaps they are hoping that there soon will be more time to go back and actually finish them, something less likely to happen as the code gets messier, or perhaps it is unintentionally by lack of required skills. Either way, the debt is in their code and is collecting interest until dealt with.

If the term Techical Debt is being reserved for decisions to design systems using last year's 1.0 technology instead of a brand new 2.0(RC1) solution, then I need a new name for that other kind of debt. Creative phrases like Deficit Programming or Ignorance Tax comes to mind, but they have a quite elitist and harsh ring to them, and seem less useful as metaphors when discussing causes and consequences of messy code with managers.

Is it time to reclaim (the term) Technical Debt and make it also incorporate messy code, or is there a better name for it? Write your suggestions in the comments!

How to write an automated test for code that calls System.exit()

The other day I came across some code that during certain conditions was expected to call System.exit(). Naturally I wanted test coverage for that code too, but since any test calling the method in question would terminate the entire testrun I had to find a different approach. Here is one strategy that can be used.

Assume we need to write a test for the following simple method. (Yep, I just made this one up.)

    public void inconceivable() {
        System.exit(42);
    }

I can not just call the method in a JUnit test like this (but feel free to try it :-)).

    @Test
    public void shouldCallSystemExit() {
        new ObjectUnderTest().inconceivable();
        // Assert what now?
    }

One way to make it possible is by utilizing a SecurityManager. By installing a custom security manager I can prevent the exit from actually happen. The following implementation overrides checkExit() to throw an exception whenever a call to System.exit() is made. By also overriding checkPermission() to do nothing, I allow myself to remove the security manager again, after it has been installed.

class ExceptionOnExitSecurityManager extends SecurityManager {
    @Override
    public void checkExit(int status) {
        super.checkExit(status);
        throw new SystemExitException(status);
    }

    @Override
    public void checkPermission(Permission perm) {
        // Override to allow removal of this security manager
    }
}

A custom exception makes it really easy to access the status code.

class SystemExitException extends SecurityException {
    int statusCode;
    SystemExitException(int statusCode) {
        this.statusCode = statusCode;
    }
}

Now I am ready to write my test.

    @Test
    public void shouldCallSystemExit() {
        System.setSecurityManager(new ExceptionOnExitSecurityManager());
        try {
            new ObjectUnderTest().inconceivable();
            fail("Did not call System.exit()");
        } catch (SystemExitException e) {
            assertEquals(42, e.statusCode);
        }
        System.setSecurityManager(null);
    }

This test will fail nicely if System.exit() is never called, or if it is called with a different status code than expected. Now the expected behaviour is documented and verified, and my test coverage moved up a notch.

Do you have a different strategy for this type of situations, or do you see any problems with this approach? Please share it in the comments!