1

Testing With The JUnit FramworkTesting With The JUnit Framwork

Carl-Fredrik Sørensen, PhD Fellow

mailto:carlfrs@idi.ntnu.no

2

TestingTesting

Not closely integrated with development. prevents measurement of the progress of development. can't tell when something starts working or when something

stops working.

JUnit to cheaply and incrementally build a test suite that helps to:– measure your progress,– spot unintended side effects.– focus your development efforts.

3

Testing with JUnitTesting with JUnit

Automatic testing framework.– Acceptance tests.– Integration test.– Unit test.

Reports the number of defects graphically.May create many tests for each method.

4

JJUUnitnit

JUnit– Defines how to structure test cases – Provides the tools to run them.

Implement a test as a subclass of TestCase.

5

JUnit ExampleJUnit Example

Interplay of code and tests.– The style: to write a few lines of code, then a test

that should run, – or even better: to write a test that won't run, then

write the code that will make it run.

Example: Solve the problem of representing arithmetic with multiple currencies.

6

Example: MoneyExample: Moneyclass Money {    

private int fAmount;    private String fCurrency;   public Money(int amount, String currency) {

  fAmount= amount fCurrency= currency;    

}    public int amount() {

return fAmount;     }    

public String currency() {    return fCurrency;     }}

7

Example: MoneyExample: Money

public Money add(Money m) {

    return new Money(amount()+m.amount(), currency());

}

8

JUnitJUnitDefine MoneyTest as a subclass of TestCase. Put MoneyTest in the same package as the

classes under test access to the package private methods. – Add method testSimpleAdd, that will exercise the

simple version of Money.add() above. – A JUnit test method is an ordinary method without

any parameters.

9

Example: MoneyTestExample: MoneyTest

public class MoneyTest extends TestCase {    

//…    

public void testSimpleAdd() {        

Money m12CHF= new Money(12, "CHF");  // (1)

      Money m14CHF= new Money(14, "CHF");

      Money expected= new Money(26, "CHF");        

Money result= m12CHF.add(m14CHF);    // (2)

assert(expected.equals(result));     // (3)    

}

}

10

Developing TestsDeveloping Tests

public void testEquals() {    

Money m12CHF= new Money(12, "CHF");

  Money m14CHF= new Money(14, "CHF");    

assert(!m12CHF.equals(null));

 assertEquals(m12CHF, m12CHF);

assertEquals(m12CHF, new Money(12, "CHF")); // (1)

assert(!m12CHF.equals(m14CHF));

}

11

Developing TestsDeveloping Testspublic boolean equals(Object anObject) {

if (anObject instanceof Money) {      

   Money aMoney= (Money)anObject;        

return aMoney.currency().equals(currency())

  && amount() == aMoney.amount();    

}  

  return false;

}

Override the method hashCode whenever you override method equals.

12

AssertionsAssertions

Verification by calling assert (inherited from TestCase). – Assert triggers a failure - logged by JUnit when the

argument isn't true. – TestCase defines an assertEquals convenience method.

Logs the printed value of the two objects if they differ. – Shows why a test failed in a JUnit test result report.

Logged as a string representation created by toString.

13

Test FixtureTest Fixture

public class MoneyTest extends TestCase {  

  private Money f12CHF;

private Money f14CHF;

  protected void setUp() {

     f12CHF= new Money(12, "CHF");

     f14CHF= new Money(14, "CHF");    

}

}

14

Tests RefactoredTests Refactoredpublic void testEquals() {

  assert(!f12CHF.equals(null));

assertEquals(f12CHF, f12CHF);

  assertEquals(f12CHF, new Money(12, "CHF"));    

assert(!f12CHF.equals(f14CHF));

}

public void testSimpleAdd() {

  Money expected= new Money(26, "CHF");

  Money result= f12CHF.add(f14CHF);

  assert(expected.equals(result));

}

15

Running of TestsRunning of Tests

Two additional steps are needed to run the two test cases:1. define how to run an individual test case,

2. define how to run a test suite.

JUnit supports two ways of running single tests:– static.– dynamic.

16

17

JUnit ReviewJUnit Review (1) (1)

In general: development will go much smoother writing tests a little at a time when developing.

When imagine of how the code will work, capture the thoughts in a test.

Test code is just like model code in working best if it is factored well.

18

JUnit ReviewJUnit Review (2) (2)

Keeping old tests running is just as important as making new ones run.

The ideal is to always run all of your tests. When you are struck by an idea, defer thinking

about the implementation. First write the test. Then run it. Then work on the implementation.

19

Testing PracticesTesting Practices (1) (1)

Martin Fowler: "Whenever you are tempted to type something into a print statement or a debugger expression, write it as a test instead.”

Only a fraction of the tests are actually useful. – Write tests that fail even though they should work,

or tests that succeed even though they should fail. – Think of it is in cost/benefit terms. You want tests

that pay you back with information.

20

Testing PracticesTesting Practices (2) (2)

Receive a reasonable return on your testing investment: – During Development. – During Debugging.

Caution:– Once you get them running, make sure they stay running.

Ideally, run every test every time you change a method. Practically, the suite will soon grow too large to run all

the time.

21

Testing PracticesTesting Practices (3) (3)

Try to optimise your set-up code so you can run all the tests.

Or, – create special suites that contain all the tests that might

possibly be affected by your current development. – run the suite every time you compile. – make sure you run every test at least once a day: overnight,

during lunch, during one of those long meetings….

22

ReferencesReferences

http://www.junit.org/

23

QuestionsQuestions