Because tool vendors, in order to get the most out of JUnit, used
internal APIs, this caused JUnit maintainers some headaches in moving
JUnit forward, as explained in this article by Nicolai
Parlog.
JUnit 5 breaks new ground mainly because of its
built in separation of concerns into two areas:
An API used to write tests
A mechanism to discover and run those tests.
For that reason, JUnit 5 was split into three sub
projects:
JUnit Jupiter – the API to write tests
JUnit Platform – the API to discover and run tests
JUnit Vintage – provide backward compatibility to run JUnit 3 and 4 tests.
For this post, I’ll use Eclipse, but you should be able to use any IDE you like.
$ cd ~/home/projects/learn
$ git clone https://github.com/makotogo/JUnit5MavenDemo
Next, I’ll start Eclipse, and import the code.
Go to File > Import…
Choose Maven > Existing Maven Projects.
Navigate to the folder where you cloned the github repo (in my case it’s ~/home/projects/learn/JUnit5MavenDemo).
Click Finish.
The class under test is very simple:
package com.makotojava.learn.junit5.demo;
public class App {
public long add(long[] operands) {
// Compute the sum
long ret = 0;
if (operands == null) {
throw new IllegalArgumentException("Operands argument cannot be null");
}
if (operands.length == 0) {
throw new IllegalArgumentException("Operands argument cannot be empty");
}
for (long operand : operands) {
ret += operand;
}
return ret;
}
}
Next, let’s look at the JUnit5App class. I’ll show it in pieces and explain the pieces as I go. Please refer to the full code listing in your IDE if you need more context.
package com.makotojava.learn.junit5.demo;
import static org.junit.jupiter.api.Assertions.assertAll;
import static org.junit.jupiter.api.Assertions.assertEquals;
import static org.junit.jupiter.api.Assertions.assertThrows;
import org.junit.jupiter.api.AfterAll;
import org.junit.jupiter.api.AfterEach;
import org.junit.jupiter.api.BeforeAll;
import org.junit.jupiter.api.BeforeEach;
import org.junit.jupiter.api.DisplayName;
import org.junit.jupiter.api.Nested;
import org.junit.jupiter.api.Test;
import org.junit.platform.runner.JUnitPlatform;
import org.junit.runner.RunWith;
@RunWith(JUnitPlatform.class)
@DisplayName("Testing using JUnit 5")
public class JUnit5AppTest {
private App classUnderTest;
@BeforeAll
public static void init() {
// Do something before ANY test is run in this class
}
@AfterAll
public static void done() {
// Do something after ALL tests in this class are run
}
@BeforeEach
public void setUp() throws Exception {
classUnderTest = new App();
}
@AfterEach
public void tearDown() throws Exception {
classUnderTest = null;
}
Notice the JUnit package names all begin with org.junit.jupiter.api. The JUnit package names have changed.
Next notice the @RunWith annotation and its JUnitPlatform.class argument. This allows tests written using JUnit Jupiter to run with a tool (like Eclipse) that does not yet natively support JUnit 5.
There is also the @DisplayName annotation, which tells JUnit to use the String argument (e.g., “Testing using JUnit 5”) rather than the default, which is the fully qualified test class name.
Then there are these annotations:
BeforeAll – tells JUnit to run this method once before all test methods have run.
BeforeEach – tells JUnit to run this method before each test method.
AfterEach – tells JUnit to run this method after each test method.
AfterAll – tells JUnit to run this method once after all test methods have run.
Next, let’s look at the testAdd() method:
@Test
@DisplayName("When numbers are > 0")
public void testAdd() {
assertAll(
() -> {
//
// Test #1
long[] numbersToSum = { 1, 2, 3, 4 };
long expectedSum = 10;
long actualSum = classUnderTest.add(numbersToSum);
assertEquals(expectedSum, actualSum);
},
() -> {
//
// Test #2
long[] numbersToSum = new long[] { 20, 934, 110 };
long expectedSum = 1064;
long actualSum = classUnderTest.add(numbersToSum);
assertEquals(expectedSum, actualSum);
},
() -> {
//
// Test #3
long[] numbersToSum = new long[] { 2, 4, 6 };
long expectedSum = 12;
long actualSum = classUnderTest.add(numbersToSum);
assertEquals(expectedSum, actualSum);
});
}
First, we tell JUnit that this is a test method by annotating it with the @Test annotation.
Next, notice the assertAll() method. This actually runs three separate tests, each of which calls assertEquals to verify the actual result matches the expected result. No big deal, right? Well, if you’ve used JUnit 4, you know that if the first of these assertEquals() calls fails then the next two are simply not run. This is not the case with assertAll. All of the statements within the lambda are run, and the results are reported as a group.
Finally, I want to point out a new JUnit 5 annotation: @Nested. Take a look at this code from JUnit5AppTest.java:
@Nested
@DisplayName("When numbers to add are < 0")
class NegativeNumbersTest {
private App classUnderTest;
@BeforeEach
public void setUp() throws Exception {
classUnderTest = new App();
}
@AfterEach
public void tearDown() throws Exception {
classUnderTest = null;
}
@Test
@DisplayName("Three tests with numbers {
//
// Test #1
long[] numbersToSum = { -1, -2, -3, -4 };
long expectedSum = -10;
long actualSum = classUnderTest.add(numbersToSum);
assertEquals(expectedSum, actualSum);
},
() -> {
//
// Test #2
long[] numbersToSum = { -20, -934, -110 };
long expectedSum = -1064;
long actualSum = classUnderTest.add(numbersToSum);
assertEquals(expectedSum, actualSum);
},
() -> {
//
// Test #3
long[] numbersToSum = new long[] { -2, -4, -6 };
long expectedSum = -12;
long actualSum = classUnderTest.add(numbersToSum);
assertEquals(expectedSum, actualSum);
});
}
}
This annotation lets us create an inner test class within the main test class. This keeps the code more structured and orderly, while keeping code together that tests the same class under test.
The @DisplayName annotation helps as well, and the results of any tests run in the @Nested class are reported “indented” relative to the main test class.
The nesting can be arbitrary also. So you can create @Nested classes within @Nested classes (within @Nested classes, and so forth) to an arbitrary level of nesting, as you see fit, and as makes sense for what you’re trying to test.
One last thing I want to point out about @Nested classes: they may each have their own @BeforeEach and @AfterEach lifecycle methods. So if you need to do special initialization, for example, you can do that outside of the main class’ @BeforeEach and @AfterEach callbacks (which still run, by the way, so keep that in mind). Because of the way the @Nested inner classes are created, they may NOT have their own @BeforeAll and @AfterAll lifecycle callbacks. Sorry.
I hope you enjoyed this brief look at JUnit 5. Please check out the video below on my YouTube channel for a more complete look at the code.
Okay, so you know I do technology for a living. Most of it is not very interesting to me (I’m sick of all the Windows 8 hype… buy it or don’t buy it, whatever!).
But this JavaWorld article about Classfile is very cool. I’ve always loved compiler theory way back to my CORBA days, where we would parse Interface Definition Language (IDL) into Abstract Syntax Trees (ASTs) and generate C++ code. But I digress.
Classfile is a library that lets you roll up classfiles without using javac to do it. Why is this interesting? Well, you can (in theory) take any logical construct and express it on the JVM without writing Java language code. So, imagine creating an app that you speak natural language into, your instructions are translated into a classfile that is immediately executed on the JVM.
I think it would be super cool to create, say, presentations by simply speaking what you want displayed, and it appears:
Me: “New Presentation” (Presentation appears)
Me: “Create a shape and place it in the top left corner” (“What shape do you want?”)
Me: “Square” (Square appears in the top left corner)
Me: “Move shape down and to the right” (square moves down and to the right)
Me: “More” (square moves more down and more to the right)
Me: “Save” (“Where do you want to save it?”
Me: “Desktop” (presentation is saved to my desktop)
You get the idea. Language parsing has gotten really good. And apps like Siri are pretty cool, but at some point businesses will want to exploit the power of natural language processing and dynamic scripting to produce applications that power the business. And utilities like Classfile will provide the ability to remove the middle-man (the programming language) and go right to the JVM. I think THAT is cool.
