Unit Testing – a quick start guide to JUnit

JUnit is the de facto standard framework for writing Java unit tests. As scala is a language that creates Java classes you can also write JUnit tests for scala classes, either in scala or Java itself.

A quick way to get started would be to download eclipse for Java developers from here (you will need Java installed).

Once downloaded, open eclipse and create a new Java Project called Test, accepting the defaults.

Expand the Test project and right-click on the src folder, choosing New and then JUnit Test Case. You may need to filter the options to find JUnit and JUnit Test Case.

In the next dialog enter TestString for the Name and com.test for the package. You should be prompted whether to add JUnit to the project build path, choose Yes.

Depending on any options for code generation, you should now have a new class that looks roughly like this:

package com.test;

import static org.junit.Assert.*;
import org.junit.Test;

public class StringTest {

	public void test() {
		fail("Not yet implemented");

When we run this class JUnit will automatically invoke the test() method because it has a @Test annotation. Let’s try it – right-click the StringTest class and choose Run As -> JUnit Test.

The failure in the JUnit panel should contain a failure trace that looks something like this:

java.lang.AssertionError: Not yet implemented
	at com.test.StringTest.test(StringTest.java:11)

This is because we have a line in out test saying ‘fail’. If we just remove this we will have an empty test that passes, but where’s the fun in that. Let’s make an assertion instead. Replace the method contents to look like this:

public void test() {
  String name = "Vinny";
  assertEquals(5, name.length());

Now when we run it there is no failure trace, because the length (number of characters) of the String “Vinny” is 5. Change the number from 5 to a different integer value and the test will fail. This is our first JUnit test, we didn’t create our own class to test but did test something, namely the ‘length()’ method of the String class.

By convention we would have a test class in a folder called src/test/java. Typically we would have the package of our Test class (what we call a TestCase) in the same package as the class being tested.


Functional Programming: Immutability

This is where functional programming can seem to be quite inaccessible to Java developers. As a Java developer we are used to distinguishing between that which is stateful and therefore an object and that which is stateless and can be just a class variable or method. To try to write our everyday code without anything mutable seems almost impossible. It isn’t but does rely on having to think carefully about how we write our functions.

In Scala, state and mutability become the following concerns:

  • Mutable variables should be avoided unless completely necessary.
  • Functions should not have side effects – running a true function for a given value should always return the same value and have as small a footprint as possible.


One part of avoiding side effects is favouring constants over variables. In Scala the two are declared using different keywords – var will create a variable, val will create a constant.


final String pageName = "login";
int index = 0;


val pageName = "login"
var index = 0

Writing code without variables can be particularly hard but, with Scala allowing code written in the Java style, is not entirely necessary.

No Side Effects

This means writing code that has a minimal footprint, it hopefully does not matter how many times a method is run, the return value is always the same and it does not affect its environment. In practice this tends to be about writing atomic, encapsulated methods. A key principle of functional programming in Scala is avoid shared state.

This is a bigger subject than this blog post might suggest and this is just an introduction. Avoiding variables can be incredibly hard and also has a big part to play in another big subject in functional programming – recursion.