Up and Running with JUnit

Because a picture of G-Unit is much more appealing than one of JUnit.

If you’ve had the pleasure of working with other testing frameworks, you may find yourself dismayed by JUnit (or rather, frustrated by the Java ecosystem). No fear, your n00b guide to JUnit is here.

Before we dive into the process of installing and integrating JUnit, I want to introduce fundamental principles of testing. I’ve written about RSpec before (here and here), but haven’t really delved into the underlying philosophy of test-driven development.

First things first, a unit test is a piece of code that executes a specific functionality in the code to be tested and asserts a certain behavior or state. A unit test targets a small unit of code, e.g., a method or a class. All of my tests have been unit test and I have not explored integration tests, which is concerned with the interaction between components, and performance tests, which tests the speed of the application.

Secondly, Uncle Bob has three guiding rules for TDD:

• First Law: You may not write production code until you have written a failing unit test.
• Second Law: You may not write more of a unit test than is sufficient to fail, and not compiling is failing.
• Third Law: You may not write more production code than is sufficient to pass the currently failing test.

And third, I want to impart some general suggestions from Clean Code. Unit tests, like the code that they’re testing, should exemplify “clarity, simplicity, and density of expression.” It is easy to think code first, test second — but in a code base where tests drive the code, test holds the utmost importance.

In classic Uncle Bob trope, Uncle Bob shares a story about working with a team that is unable to maintain their tests and how it slows down their workflow. The team later decides to lose their test suite altogether, but things break and fall apart. He warns: “If you don’t keep your tests clean, you will lose them. And without them, you lose the very thing that keeps your production code flexible.” Tests essentially abate fear (of introducing bugs, etc).

The idea behind unit testing is that you should test a single concept in each test function. While the single assert rule is a “good guideline,” it would not be out of line to have multiple asserts in a test so long as it was testing the same concept.

Configuring JUnit can be a tad bit confusing at first. I found this comprehensive guide to be a useful reference. Here is what you need to do:

1. Download and install the JAR file for JUnit.
2. Create a JUNIT home folder and store the JAR file here.
3. Identify where your Java is stored.
4. Set up your environment variable in .bash_profile to point to where the JUnit JARs are placed.

export JAVA_HOME=/Library/Java/Home
export JUNIT_HOME=/Library/JUNIT

5. If you’re using IntelliJ, you’ll want to create a test by using Ctrl+Shift+T keyboard shortcut to Create Test. The first time that you do this, a dialog will appear and ask you which testing framework you’d like to use.

6. Write a test that fails and then write a code to make the test pass. There are several tutorials that demo running the test from the command-line, but if you’re using IntelliJ, check out this comment on Stack Overflow (2nd response).

Happy testing!