JAVA 8 - Putting your code to the test. JUnit test.

Up until now, most of our methods we’ve created have been driven from our main() method.
It seems a good time to move away from that, and start using Junit test methods to drive the testing of what we’re building as we move onwards, and do away with the need for that main() function.
Most courses leave it until the end, so you don’t have much time to get used to them.  However right now, we know enough Java to use them, and they’ll help tidy up our code no end.

So let's get down to business ...

Mulan puts herself to a different kind of test

Adding JUnit

JUnit doesn’t come “out of the box” as standard in Java – you have to add the library and include the include command for it.

Right click on your project and select Add Libraries ...

Then select JUnit, Next then Finish.

Finally in your code, you use the import command, which you put at the top of your code, before your class declaration.

There are a huge library of features out there which are already written, and using them can help you avoid reinventing the wheel.  It's well worth Googling what kind of libraries are available.

So many libraries to choose from!

When you've found one, you need to add it to your build path as above, then explicitly add an include statement for the element you want to use.

JUnit's @Test methods

Once set up, any method which is prefixed by @Test is recognised as a JUnit test.  This will mean that once the Java has compiled after you perform changes, it will run all @Test methods to perform checks on the code.

The problem with our code so far, it runs things and shows results to screen, but it never really checks anything.  Within JUnit tests you can have any set of Java statement you can imagine … and you can also go one better, with assert commands.

An assert command is a bit like an if command.  You give it an instruction, which has to result in a true or false command.  However if that assertion returns something different to what you expected, it raises an error.

Lets look at the two basic types, assertTrue and assertFalse

assertTrue(“Error msg 1”, condition1);

This command will raise an error if condition1 is false – the error in the log will be made more visible with the text “Error msg 1”.  Ideally you want your error message to be unique, so it’s easy to trace, and helpful when you do see it.

assertFalse(“Error msg 2”, condition2);

This command is the opposite of the previous command.  This time it will raise an error if condition2 is false.

There are other assert commands, which you should look up, however these are the ones you’ll use predominantly.

Returning to 2 + 2 = 5

Let’s look at our oh-so-fun “learning to count with Big Brother” program.  We drove the outputs of our previous version with the main() method calling our calculation method time and again …

I’m going to rewrite this now to use @Test methods.  Ideally you have a lot of test methods, which really just test one thing.  As you can see, I’ve created a test for each sum.

I wrote onePlusTwo slightly different to the rest - although it still does the same job.  This was to show you that you don’t only have to have assert commands within your JUnit test method.

Sadly this programmer must have been swayed by the works of Goldstein – and in a moment of suicidal madness wrote the JUnit test twoAndTwo, which treasonously checks for the return value of 4.

Thankfully, this test rightly fails in the Junit dashboard …

Because 2 + 2 have always been equal to 5!


The code for this can be found here on Github.


Extension material

You might want to look up in detail what you can do with the include command.

Look up other kinds of assert you can do.

We've not covered it here, but in addition to @Test, you can also have @Before and @After methods - look up to see what they do.