Unit Testing

Unit testing is one of my favorite time saving techniques. I am amazed at the number of people that I talk to that don't write unit tests, because it takes too long, or it feels like writing it twice, or a handful of other reasons that I have heard.

Plain and simple, if used right, unit tests can save you a whole bunch of time. It is one of those spend-a-little-to-save-a-lot techniques. I find this to be particularly true in web development.

I get rather sick of manually testing my stuff for a web application. Each little change is a complete chore. You have to

1. Make the change
2. Deploy the new app
3. Possibly restart the web server
4. If necessary, log in
5. Navigate to the page in question
6. Perform activity under examination (potentially a lot of clicks involved here)
7. Evaluate the displayed results

Not only is this time consuming, but it is also incredibly prone to error conditions. What if something didn't deploy right? What if the web server is bugging out? Maybe the displaying of the results is incorrect. What if you hit the wrong link, or typed in the wrong value, or whatever. You get the idea.

Another one I see people do sometimes is that they will write little main() functions in their code, in order to test their functionality. Guess what - that is basically what a unit test is! Only now you are adding more code, and getting less support by your IDE.

Unit tests are basically just little code snippets that most modern IDEs know how to support natively. They can be automated, they can provide reports, and better yet, they can be rerun time and time again, at just a single click of a button.

Unit tests really are not all that scary, once you get into them. Here is an example of a very simple test that will always pass:

public class TestMyClass
{
     @Test
    public void testMyClass() {
        assertTrue(1 == 1); 
    }
}

Not too bad, right? This will always tell you, every time you run the tests, that 1 does in fact equal 1. Not all that helpful, but it is a start. So, let's go with a more real-world scenario:

public class TestMailService
{
     @Test
    public void testSetForwarding() {
        MailService mailService = new MailService();
        mailService.setForwarding("fromaddress@domain.com",
            "toAddress@domain.com");


        assertTrue(
            mailService.getForwardingAddress( "fromaddress@domain.com" ).
            equals( "toAddress@domain.com" ));

    }

}

So, this is a slightly meatier example that tests a mail service that sets up forwarding. With this little snippet in place, you can determine that your mail service library is successfully setting and retrieving the forwarding address correctly. If you or somebody else does something that breaks that functionality, you do not need to experience that through your web browser in order to become aware of the problem.

This is by no means an exhaustive study on unit tests. It really only scratches the surface. If you have not used them before, though, I highly recommend you look into it. Save yourself some time, and make your coding world just that much better.