1. COMP23420 Sem 2 week 7
Unit testing and JUnit
John Sargeant
johns@cs.man.ac.uk
REMINDER: PLEASE ENSURE YOUR PHONE IS
SWITCHED OFF DURING LECTURES
C om b ining th e s tre ngth s of U M IS T and
Th e Victoria U nive rs ity o f M anch e s te r

2. Overview
• Introduction
• Java features for Junit 4
• JUnit 4
• Example unit tests
C om b ining th e s tre ngth s of U M IS T and
Th e Victoria U nive rs ity o f M anch e s te r

3. Introduction
• Reminder: unit testing is testing one unit (class) at a
time – although most classes depend on other
classes
• Can be black-box (based on the javadoc) or white
box (based on the code).
• In most cases black-box is better.
• JUnit is a Java framework for unit testing
• JUnit 4 is a big improvement on previous versions,
but requires some Java features you may not know.
C om b ining th e s tre ngth s of U M IS T and
Th e Victoria U nive rs ity o f M anch e s te r

4. Static import
Added in Java 1.5. Reminder: a normal import, e.g.
import java.util.Calendar;
Allows us to refer just to Calendar rather than having to
say java.util.Calendar; every time.
Similarly a static import.e.g.
import static java.util.Calendar;
Allows us to refer to all the static features of the
Calendar class by their short names, e.g.
DAY_OF_WEEK rather than Calendar.DAY_OF_WEEK
C om b ining th e s tre ngth s of U M IS T and
Th e Victoria U nive rs ity o f M anch e s te r

5. Annotations
• Also added in Java 1.5. Ignored by the compiler, but
intended to be used by other tools.
• E.g. suppose you have a tool which reminds you of
programming tasks you need to do:
@Remind(period=weekly)
public Driver pickOptimumDriver() {
return null; // Not yet implemented
}
Annotation applies to the immediately following class or
method.
C om b ining th e s tre ngth s of U M IS T and
Th e Victoria U nive rs ity o f M anch e s te r

6. Reflection
• The ability to represent programming language
constructs such as classes and methods within the
language itself.
• “Not a first year topic” – JTL.
• Instances of the class called Class represent classes.
• Can be obtained with .class, e.g. Calendar.class
gives an object representing the Calendar class.
• Can get mind-bending, e.g. Class.class is an
instance of class Class which represents the class
Class.
C om b ining th e s tre ngth s of U M IS T and
Th e Victoria U nive rs ity o f M anch e s te r

7. Example code to test
public class Sorter {
private int[] _numbers;
public Sorter(int[] numbers) {
_numbers = numbers;
}
public int[] getNumbers() {
return _numbers;
}
public void sort() {
// Not implemented yet
}
}om VictoriathUenive rs ity os fof U M ISeTs te r
C
Th e
b ining s tre ngth
M anch
and

8. Test class (1)
import org.junit.*;
import static org.junit.Assert.*;
public class TestSorter {
private static Sorter _sorter;
private static boolean isSorted(int[] array) { …. }
@Before
public void setUp() {
_sorter = new Sorter(new int[] { 3, 7, 1, 4, 6 })
}
C om b ining th e s tre ngth s of U M IS T and
Th e Victoria U nive rs ity o f M anch e s te r

9. Test class (2)
@Test
public void testUnsorted() {
assertFalse(isSorted(_sorter.getNumbers()));
}
@Test
public void testSorted() {
_sorter.sort();
assertTrue(isSorted(_sorter.getNumbers()));
}
}
C om b ining th e s tre ngth s of U M IS T and
Th e Victoria U nive rs ity o f M anch e s te r

10. What happens
The first test succeeds, the second fails, giving an
AssertionError.
Now if we actually implement sorting:
public void sort() {
Arrays.sort(_numbers);
}
Both tests should succeed.
C om b ining th e s tre ngth s of U M IS T and
Th e Victoria U nive rs ity o f M anch e s te r

11. @Before and @BeforeClass
• Code run before or after a test to set things up to tidy
up afterwards is called a Fixture.
• @Before indicates a fixture to be run before every
test. The setup method which follows must not be
static.
• @BeforeClass indicates a fixture to be run just once.
The setup method must be static.
• @After and @AfterClass are the same for code run
afterwards.
C om b ining th e s tre ngth s of U M IS T and
Th e Victoria U nive rs ity o f M anch e s te r

12. Running tests
The test class has no main() so how do we run it?
Either from the command line, with the JUnit Jar file on
the CLASSPATH:
java org.junit.runner.JUnitCore TestClass
Or from within an IDE, e.g. in Netbeans, right click on
the Java file, select Tools -> JUnit (make sure you
select JUnit 4).
C om b ining th e s tre ngth s of U M IS T and
Th e Victoria U nive rs ity o f M anch e s te r

13. Test suites
• Often we want to run a bunch of tests together – a
test suite. This is done with the @RunWith annotation
and the test classes to use listed using reflection:
@Runwith(Suite.class)
@SuiteClasses(DepartureTimesTest.class,
RosterOrderingTest.class,
DriverAllocationTest.class)
public class RosterTest() {
}
C om b ining th e s tre ngth s of U M IS T and
Th e Victoria U nive rs ity o f M anch e s te r

14. Other things you can do
JUnit 4 allows you to other good things such as:
• Parameterise tests so you can run the same test
many times with different parameters
• Test the exception handling behaviour of your code.
More information at JUnit,org and there are many
tutorials on the web (make sure it’s JUnit 4, not 3).
C om b ining th e s tre ngth s of U M IS T and
Th e Victoria U nive rs ity o f M anch e s te r

15. Black box vs. White Box
• JUnit test classes are separate from the classes they
are testing, so can only use the public interface
• If you have access to the private stuff, you could
make use of that knowledge..
• E.g. an amount of Money represented as an int –
won’t work for large numbers
• But generally Black Box testing is preferable – also
helps to clarify requirements.
• E.g. testing for large amounts is an obvious thing to
do anyway.
C om b ining th e s tre ngth s of U M IS T and
Th e Victoria U nive rs ity o f M anch e s te r

16. General testing hints
• Real-world data (e.g. 358 timetable) is messy – check
that you’ve covered all the cases.
• Test small parts before assembling them into bigger
parts – make sure the easy tests get done.
• Make sure known bugs and things not yet
implemented are documented using e.g. Bugzilla.
• When doing system testing, use a variety of real
users – people will use it in ways you don’t expect.
• Don’t assume – check!
C om b ining th e s tre ngth s of U M IS T and
Th e Victoria U nive rs ity o f M anch e s te r

17. Weeks 8-11 (Provisional)
• Weeks 8 - 10 Software Architecture design (LZ)
• Week 11 review of second semester (JS/LZ)
• ~ 1 week before the exam: exam revision session
(JS/LZ). Mock online exam will also be available.
C om b ining th e s tre ngth s of U M IS T and
Th e Victoria U nive rs ity o f M anch e s te r