JUNIT

Jan31,2015

Test suites
2

Obviously you have to test your code to get it

working in the first place

You can do ad hoc testing (testing whatever occurs to you at

the moment), or
You can build a test suite (a thorough set of tests that can
be run at any time)

Disadvantages of writing a test suite

Its a lot of extra programming

You dont have time to do all that extra work

Truebut use of a good test framework can help quite a bit

FalseExperiments repeatedly show that test suites reduce
debugging time more than the amount spent building the test
suite

Advantages of having a test suite

Your program will have many fewer bugs

It will be a lot easier to maintain and modify your program

This is a huge win for programs that, unlike class assignments,

get actual use!

Example: Old way vs. new

way
int max(int a, int b) {
if (a > b) {
return a;
} else {
return b;
}

@Test
void testMax() {
assertEquals(7, max(3, 7));
assertEquals(3, max(3, -7));
}

}
void testMax() {
int x = max(3, 7);
if (x != 7) {
System.out.println("max(3, 7) gives " + x);
}
x = max(3, -7);
if (x != 3) {
System.out.println("max(3, -7) gives " + x);
}
}
public static void main(String[] args) {
new MyClass().testMax();
}

XP approach to testing
4

In the Extreme Programming approach,

Tests are written before the code itself

If code has no automated test case, it is assumed not to work
A test framework is used so that automated testing can be
done after every small change to the code

This may be as often as every 5 or 10 minutes

If a bug is found after development, a test is created to keep

the bug from coming back

Consequences

Fewer bugs
More maintainable code
Continuous integrationDuring development, the program
always worksit may not do everything required, but what it
does, it does right

JUnit
5

JUnit is a framework for writing tests

JUnit was written by Erich Gamma (of Design

Patterns fame) and Kent Beck (creator of XP
methodology)
JUnit uses Javas reflection capabilities (Java
programs can examine their own code)
JUnit helps the programmer:
define

and execute tests and test suites

formalize requirements and clarify architecture
write and debug code
integrate code and always be ready to release a
working version

JUnit is not included in Suns SDK, but almost all

IDEs include it

Terminology
6

A test fixture sets up the data (both objects and

primitives) that are needed to run tests

Example: If you are testing code that updates an employee

record, you need an employee record to test it on

A unit test is a test of a single class

A test case tests the response of a single method to a
particular set of inputs
A test suite is a collection of test cases
A test runner is software that runs tests and reports
results
An integration test is a test of how well classes work
together

JUnit provides some limited support for integration tests

Once more, in pictures

7

test suite

test runner

another unit test

test case (for one method)

another test case

another unit test

another test case

another test case

another test case

unit test (for one class)

test case (for one method)

another test case

test fixture

A unit test tests the

methods in a single class
A test case tests (insofar as
possible) a single method
You can have multiple test
cases for a single method

A test suite combines unit

tests
The test fixture provides
software support for all this
The test runner runs unit
tests or an entire test suite
Integration testing (testing
that it all works together) is
not well supported by JUnit

Writing a JUnit test class, I

8

import org.junit.*;
import static org.junit.Assert.*; // note static import

Declare your test class in the usual way

public class MyProgramTest {

Start by importing these JUnit 4 classes:

Declare an instance of the class being tested

You can declare other variables, but dont
give them initial values here

public class MyProgramTest {

MyProgram program;
int someVariable;

Writing a JUnit test class, II2

9

@Before
public void setUp() {
program = new MyProgram();
someVariable = 1000;
}

Define a method (or several methods) to be executed before

each test
Initialize your variables in this method, so that each test
starts with a fresh set of values

You can define one or more methods to be executed after

each test
Typically such methods release resources, such as files
Usually there is no need to bother with this method

@After
public void tearDown() {
}

A simple example
10

Suppose you have a class Arithmetic with methods int multiply(int x, int y),
and boolean isPositive(int x)

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

public class ArithmeticTest {

@Test
public void testMultiply() {
assertEquals(4, Arithmetic.multiply(2, 2));
assertEquals(-15, Arithmetic.multiply(3, -5));
}

@Test
public void testIsPositive() {
assertTrue(Arithmetic.isPositive(5));
assertFalse(Arithmetic.isPositive(-5));
assertFalse(Arithmetic.isPositive(0));
}
}

Assert methods I
11

Within a test,

An assert method is a JUnit method that performs a test, and

throws an AssertionError if the test fails

JUnit catches these Errors and shows you the result

static void assertTrue(boolean test)

static void assertTrue(String message, boolean test)

Call the method being tested and get the actual result
Assert what the correct result should be with one of the assert
methods
These steps can be repeated as many times as necessary

Throws an AssertionErrorif the test fails

The optional message is included in the Error

static void assertFalse(boolean test)

static void assertFalse(String message, boolean test)

Throws an AssertionErrorif the test fails

Example: Counter class

12

For the sake of example, we will create and test a

trivial counter class

We write the test methods before we write the code

The constructor will create a counter and set it to zero

The increment method will add one to the counter and return
the new value
The decrement method will subtract one from the counter
and return the new value
This has the advantages described earlier
However, we usually write the method stubs first, and let
the IDE generate the test method stubs

Dont be alarmed if, in this simple example, the

JUnit tests are more code than the class itself

JUnit tests for Counter

13

public class CounterTest {

Counter counter1; // declare a Counter here

@Before
void setUp() {
counter1 = new Counter(); // initialize the Counter here
}
@Test
public void testIncrement() {
assertTrue(counter1.increment() == 1);
assertTrue(counter1.increment() == 2);
}

@Test
public void testDecrement() {
assertTrue(counter1.decrement() == -1);
}

Notethateachtest
beginswithabrand
newcounter

Thismeansyoudont
havetoworryabout
theorderinwhichthe
testsarerun

The Counter class itself

14

public class Counter {

int count = 0;

public int increment() {

return count += 1;
}
public int decrement() {
return count -= 1;
}

public int getCount() {

return count;
}

Is JUnit testing overkill for

this little class?
The Extreme Programming
view is: If it isnt tested, it
doesnt work
You are not likely to have
many classes this trivial in a
real program, so writing
JUnit tests for those few
trivial classes is no big deal
Often even XP programmers
dont bother writing tests
for simple getter methods
such as getCount()
We only used assertTrue in
this example, but there are
additional assert methods

Warning: equals
15

You can compare primitives with ==

Java has a method x.equals(y), for comparing objects

assertEquals(expected, actual) uses == or equals

To define equals for your own objects, define exactly
this method:
public boolean equals(Object obj) { ... }

This method works great for Strings and a few other Java classes
For objects of classes that you create, you have to define equals

The argument must be of type Object, which isnt what you

want, so you must cast it to the correct type (say, Person):
public boolean equals(Object something) {
Person p = (Person)something;
return this.name == p.name; // test whatever you like here
}

Well talk much more about equals later

Assert methods II
16

assertEquals(expected, actual)
assertEquals(String message, expected, actual)
expected and actual must be both objects or the same
primitive type
For objects, uses your equals method, if you have defined it
properly, as described on the previous slide

assertSame(Objectexpected, Objectactual)
assertSame(String message, Objectexpected, Objectactual)
Asserts that two arguments refer to the same object

assertNotSame(Objectexpected, Objectactual)
assertNotSame(String message, Objectexpected, Objectactual)
Asserts that two objects do not refer to the same object

Assert methods III

17

assertNull(Objectobject)
assertNull(String message, Objectobject)
Asserts that the object is null (undefined)

assertNotNull(Objectobject)
assertNotNull(String message, Objectobject)
Asserts that the object is null

fail()
fail(String message)
Causes the test to fail and throw an AssertionFailedError
Useful as a result of a complex test, when the other
assert methods arent quite what you want

Writing a JUnit test class, III

18

This page is really only for expensive setup, such as

when you need to connect to a database to do your
testing

@BeforeClass
public static void setUpClass() throws Exception {
// one-time initialization code
}

If you wish, you can declare one method to be executed just once,
when the class is first loaded

If you wish, you can declare one method to be executed just once,
to do cleanup after all the tests have been completed

@AfterClass
public static void tearDownClass() throws Exception {
// one-time cleanup code
}

Special features of @Test

19

@Test (timeout=10)
public void greatBig() {
assertTrue(program.ackerman(5, 5) > 10e12);
}

You can limit how long a method is allowed to take

This is good protection against infinite loops
The time limit is specified in milliseconds
The test fails if the method takes too long

Some method calls should throw an exception

You can specify that a particular exception is expected
The test will pass if the expected exception is thrown, and fail
otherwise

@Test (expected=IllegalArgumentException.class)
public void factorial() {
program.factorial(-5);
}

20

Test-Driven Development
(TDD)
It is difficult to add JUnit tests to an existing program

The program probably wasnt written with testing in mind

Its actually better to write the tests before writing

the code you want to test
This seems backward, but it really does work better:

When tests are written first, you have a clearer idea what to
do when you write the methods
Because the tests are written first, the methods are
necessarily written to be testable
Writing tests first encourages you to write simpler, singlepurpose methods
Because the methods will be called from more than one
environment (the real one, plus your test class), they tend
to be more independent of the environment

Stubs
21

In order to run our tests, the methods we are testing

have to exist, but they dont have to be right
Instead of starting with real code, we start with stubs
minimal methods that always return the same values

A stub that returns void can be written with an empty body

A stub that returns a number can return 0 or -1 or 666, or
whatever number is most likely to be wrong
A stub that returns a boolean value should usually return false
A stub that returns an object of any kind (including a String or
an array) should return null

When we run our test methods with these stubs, we

want the test methods to fail!

This helps test the teststo help make sure that an incorrect
method doesnt pass the tests

Ignoring a test
22

The @Ignore annotation says to not run a test

@Ignore("I dont want Dave to know this doesnt work")

@Test
public void add() {
assertEquals(4, program.sum(2, 2));
}
You shouldnt use @Ignore without a very good reason!

Test suites
23

You can define a suite of tests

@RunWith(value=Suite.class)
@SuiteClasses(value={
MyProgramTest.class,
AnotherTest.class,
YetAnotherTest.class
})
public class AllTests { }

JUnit in Eclipse
24

If you write your method stubs first (as on the previous slide),
Eclipse will generate test method stubs for you
To add JUnit 4 to your project:

Select a class in Eclipse

Go to File New... JUnit Test Case
Make sure New JUnit 4 test is selected
Click where it says Click here to add JUnit 4...
Close the window that appears

To create a JUnit test class:

Do steps 1 and 2 above, if you havent already

Click Next>
Use the checkboxes to decide which methods you want test cases
for;
dont select Object or anything under it

I like to check create tasks, but thats up to you

Click Finish

To run the tests:

Choose Run Run As JUnit Test

Viewing results in Eclipse

25

Bar is green if
all tests pass,
red otherwise

This test passed

Something is wrong

Depending on your
preferences, this
window might show
only failed tests

Ran 10 of
the 10 tests

No tests
failed, but...

Something unexpected
happened in two tests

This is how
long the
test took

Recommended approach
26

Write a test for some method you intend to write

Write a stub for the method

Run the test and make sure it fails
Replace the stub with code

Write just enough code to pass the tests

Run the test

If the method is fairly complex, test only the simplest case

If it fails, debug the method (or maybe debug the test);

repeat until the test passes

If the method needs to do more, or handle more

complex situations, add the tests for these first,
and go back to step 3

The End
27

Ifyoudontunittestthenyouarentasoftwareengineer,youarea
typistwhounderstandsaprogramminglanguage.
MosesJones
1.Neverunderestimatethepowerofonelittletest.
2.Thereisnosuchthingasadumbtest.
3.Yourtestscanoftenfindproblemswhereyourenotexpecting
them.
4.Testthateverythingyousayhappensactuallydoeshappen.
5.Ifitsworthdocumenting,itsworthtesting.
AndyLester