A few quick notes about using JUnit in the Eclipse IDE
The three major integrated development environments (IDEs) all provide neat integration of JUnit, making it very easy to write and run JUnit tests without having to use the command line.
Of course they differ in how they provide that integration. In IntelliJ IDEA, each valid test gets a green play button allowing the test to run by itself, and another green play button to run all the tests in a test class.
There’s no way to run a single test by itself in NetBeans, except of course when a test class contains only a single test. Still, the display of test results in NetBeans is quite straightforward and easy to understand.
I don’t use Eclipse all that often. Every time I do use Eclipse I find myself getting confused about how to do things that I take for granted in IntelliJ IDEA or NetBeans. Things like reviewing the results of a test.
So these notes about using JUnit in Eclipse are as much for my benefit as they are for yours.
The problem in Eclipse begins from the moment you have Eclipse create a project for you. Eclipse doesn’t automatically create what IntelliJ IDEA calls a “content root” for test classes’ source.
We could put a positive spin on this, saying that Eclipse is not opinionated about where test classes’ source should be placed. I find it inconvenient that such a folder is not automatically created.
However, if you click on the Next button in the New Java Project dialog box, you are presented with an opportunity to add such a folder.
Notice almost all the way on the right an icon for a new folder with a little package symbol. Click on it and name the new folder “test”.
But if you conclude the new project wizard without creating that folder, you can still create it by right-clicking on the project name in the Package Explorer and selecting New > Source Folder.
Once you’re ready to create a new test class, right-click on the class to be tested and select New > JUnit Test Case. Eclipse will show you a dialog box in which you can select JUnit 3, JUnit 4 or JUnit Jupiter.
I leave it on JUnit Jupiter (JUnit 5). Under that, there’s the source folder where Eclipse will put the test class in. The first time you invoke this for the project, it will have the project name followed by “/src”. Be absolutely sure to change that to “/test”.
If you haven’t created the test source folder yet, you won’t be able to create it from the new test case dialog box, you’ll have to exit the dialog box and take care of that in the Package Explorer.
And after that it’s all too easy to forget to put the new test in /test rather than /src.
The proper source/test separation is not a big deal in a simple test-driven development exercise, but in a real world project, or even a moderately large hobby project, it can be very helpful. So I would prefer that Eclipse be a little opinionated about this.
The other options for a test class are laid out differently from what a regular IntelliJ IDEA or NetBeans user would expect, but the difference is only superficial: you still get to choose to have the IDE generate or not generate test set-up and tear-down and what functions and procedures to generate tests for (the latter is on the “second page” of the wizard).
For the first test class of the project, Eclipse will almost certainly ask you to add the pertinent JUnit library to the build path. Just click OK on that.
For the next couple of examples I’m going to use the Fraction class, as I often do in these articles. I assume you know the basic concept of fractions from high school math, even if you don’t remember the specifics.
In FractionTest, I put in a private static instance of java.util.Random and wrote the following test:
@Test
void testToString() {
System.out.println("toString");
int numer = RANDOM.nextInt(128) + 1;
int denom = numer * (RANDOM.nextInt(128) + 1) + 1;
Fraction fraction = new Fraction(numer, denom);
String expected = numer + "/" + denom;
String actual = fraction.toString().replace(" ", "");
assertEquals(expected, actual);
}This should give us a Fraction instance like 53/107. But because I haven’t overridden toString() yet, the result might be something more like “Fraction@35a8b47”.
To run the test class, find the green play button under Eclipse’s top level menu. When the mouse hovers over it, you should see the tooltip “Run FractionTest.java”. Click it.
The test class runs. I was a little surprised to see the results come up to the left of the source editor pane, but I’m sure that can be customized so it’s on the bottom, as I expect to find it in IntelliJ IDEA or NetBeans.
The results are reported clearly enough.
There’s a failure trace below what is shown in the screenshot above. In Eclipse it shows me four pertinent lines, but when I copied and pasted to Medium, it was more like forty lines, I will only quote a few:
org.opentest4j.AssertionFailedError: expected: <125/8876> but was: <fractions.Fraction@78ac1102>
at org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:55)
at org.junit.jupiter.api.AssertionUtils.failNotEqual(AssertionUtils.java:62)
…
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:210)
You know how to make this test pass, or if not you can figure it out quickly enough, so I won’t quote the toString() override.
I like to save before running tests, but that’s not strictly necessary (and of course it’s moot in IntelliJ IDEA, unless you turn auto-save off.
So far so good. But what happens when you’ve got more tests, with some passing and some failing?
I now add a stub for a function that gives a floating point approximation of the fraction. For example, given 41/29, we expect a floating point approximation of 1.41379310, give or take a few millionths. This stub will almost certainly fail the first test:
// STUB TO FAIL THE FIRST TEST
public double numericApproximation() {
return -1.0;
}So I play the TDD game for just a little bit, first writing a test that expects a floating point approximation for 22/7 and getting it to pass by changing the tested function to always return 3.142857142857143.
JUnit 5 seems to not require a delta for comparing floating point numbers, like JUnit 4 did. Other terms for “delta” are “tolerance” and “variance.” If the expected and actual values differ by less than the delta, the test passes as if they had been exactly the same.
If the delta is omitted in a JUnit 5 test, it is then understood to be 0.0, which means there’s no margin for error. But do you really want a test failing because expected and actual differed by a tiny amount you don’t care about?
So I generally like to include a delta of 0.00000001, sometimes slightly more than that, sometimes slightly less. Here’s a test for a floating point approximation of 355/113.
@Test
void testNumericApproximationPiApprox() {
Fraction piApprox = new Fraction(355, 113);
double expected = 3.1415929203539825;
double actual = piApprox.numericApproximation();
assertEquals(expected, actual, 0.00000001);
}The difference between expected and actual turns out to be much more than 0.00000001. But it’s a little hard to read on the Failure Trace panel.
Click the Compare Actual With Expected Test Result button. It’s a little hard to find, refer to this screenshot:
It helps, but it’s not as clear as the way IntelliJ IDEA reports expected and actual value comparisons.
Don’t let these criticisms of Eclipse obscure the fact that, in the broad strokes, the three major Java IDEs are the same: each provides a convenient single program in which to write, compile, test and run Java programs. Eclipse is just not as intuitive as the other two major Java IDEs, in my opinion.
However, I gotta give credit where credit is due: the spell checker in Eclipse is much better than the one in NetBeans.