Unit Testing with JUnit

Overview

This chapter discusses unit-level testing of Java classes with JUnit. Automated unit-level testing is an essential ingredient to continuous integration and XP; accordingly, several chapters in this tutorial cover JUnit. This chapter is primarily a tutorial that introduces the JUnit framework. , "Load Testing with JUnitPerf" and , "Functional Testing with HttpUnit" illustrate techniques for using JUnit with other tools. Combined, these chapters provide thorough coverage of the JUnit framework. If code has no automated test case written for it to prove that it works, it must be assumed not to work. An API that does not have an automated test case to show how it works must be assumed un-maintainable. Software without automated test cases cannot be economically refactored. Software that that cannot be refactored cannot be extended economically-and believe me, your code will likely be in circulation longer than you think. Your alternative to automated unit-level testing is writing expensive, un-maintainable, rigid, brittle software systems that cannot be easily extended or refactored. Your code base will go the way of the dodo bird or, worse, you will be stuck maintaining it forever-a fitting punishment! When you consider the alternatives, automated unit-level is not optional. A common argument for not writing automated unit-level test cases is that you just don't have the time. Malarkey. This statement becomes a self-fulfilling prophecy. Productivity is directly related to the stability of your code base. The fewer test cases you write, the less stable your code base becomes. You spend all your time fixing unintended side effects and bugs that are coming out of the woodwork. Soon you have even less time to write tests, not to mention a stomach ulcer. Situation like this can have you running to be another member of the management ranks-and no good developer should want to do that. Get off the hamster wheel and take the time to write test cases. In , "Introduction to Extreme Programming," we discussed the synergy between refactoring and unit-level testing at length. To sum up those thoughts, without refactoring your system becomes overly complex. Refactoring means keeping your code as simple as possible and yet providing all the features for that iteration of the release. Unit-level testing proves that the code you refactored did not break: The features still work. Testing enables you to have confidence in your ability to refactor and instills courage to refactor often, which keeps your code base solid and maintainable. Working under these conditions is fruitful and rewarding-you can achieve inner peace and contentment with your code.

JUnit was written by Erich Gamma and Kent Beck. Kent Beck defined the XP methodology and is the author of the first XP tutorial, Extreme Programming Explained: Embrace Change as well as subsequent tutorials about XP. JUnit is distributed on JUnit.org under the Common Public License Version 1.0:

www.junit.org/

It's hard to measure the progress of your project without testing. In this chapter, when we talk about testing we mean automated testing. Testing is not a metric that is typically tracked; however, it can tell you when something begins working or, more importantly, when something that used to work stops working. The next section will show you how to incrementally build a test suite full of test cases that will help you measure the progress of your project and identify unintended side effects of refactoring.

To prove that their code works, some people watch the code using System.out.println or their IDE's debugger. This approach has three problems: scroll blindness, subjectivity, and lack of automation.

First, it is hard to tell if a complex system is working because so many System.out.println methods are printing so much garbage. Second (and this is very subjective), you must determine if something works by looking at a String scrolling by on a console. The string of text scrolling by may make sense the day you wrote it, but will it still make sense in three months? Third, when you make changes, things can break in unexpected ways. If you don't have an automated test, you may not test the subsystem that you broke. In fact, it may not be directly related to the subsystem you are working on for quite a while-long enough for the cobwebs of confusion to grow in your mind. Conversely, if you run an automated test several times a day or more, then you will find errors early and often. Simply put, you don't check your code into source control until all the tests run successfully.

Previous Next