Testing With The JUnit Framwork CarlFredrik Srensen Ph

Testing With The JUnit Framwork Carl-Fredrik Sørensen, Ph. D Fellow mailto: carlfrs@idi. ntnu. no 1

Testing l Not closely integrated with development. prevents measurement of the progress of development. Ø can't tell when something starts working or when something stops working. l JUnit to cheaply and incrementally build a test suite that helps to: – measure your progress, – spot unintended side effects. – focus your development efforts. 2

Testing with JUnit l Automatic testing framework. – Acceptance tests. – Integration test. – Unit test. l Reports the number of defects graphically. l May create many tests for each method. 3

JUnit l JUnit – Defines how to structure test cases – Provides the tools to run them. l Implement a test as a subclass of Test. Case. 4

JUnit Example l 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. l Example: Solve the problem of representing arithmetic with multiple currencies. 5

Example: Money class Money { private int f. Amount; private String f. Currency; public Money(int amount, String currency) { f. Amount= amount f. Currency= currency; } public int amount() { return f. Amount; } public String currency() { return f. Currency; } } 6

Example: Money public Money add(Money m) { return new Money(amount()+m. amount(), currency()); } 7

JUnit l Define Money. Test as a subclass of Test. Case. l Put Money. Test in the same package as the classes under test access to the package private methods. – Add method test. Simple. Add, that will exercise the simple version of Money. add() above. – A JUnit test method is an ordinary method without any parameters. 8

Example: Money. Test public class Money. Test extends Test. Case { //… public void test. Simple. Add() { Money m 12 CHF= new Money(12, "CHF"); // (1) Money m 14 CHF= new Money(14, "CHF"); Money expected= new Money(26, "CHF"); Money result= m 12 CHF. add(m 14 CHF); // (2) assert(expected. equals(result)); // (3) } } 9

Developing Tests public void test. Equals() { Money m 12 CHF= new Money(12, "CHF"); Money m 14 CHF= new Money(14, "CHF"); assert(!m 12 CHF. equals(null)); assert. Equals(m 12 CHF, m 12 CHF); assert. Equals(m 12 CHF, new Money(12, "CHF")); // (1) assert(!m 12 CHF. equals(m 14 CHF)); } 10

Developing Tests public boolean equals(Object an. Object) { if (an. Object instanceof Money) { Money a. Money= (Money)an. Object; return a. Money. currency(). equals(currency()) && amount() == a. Money. amount(); } return false; } l Override the method hash. Code whenever you override method equals. 11

Assertions l Verification by calling assert (inherited from Test. Case). – Assert triggers a failure - logged by JUnit when the argument isn't true. – Test. Case defines an assert. Equals 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 to. String. 12

Test Fixture public class Money. Test extends Test. Case { private Money f 12 CHF; private Money f 14 CHF; protected void set. Up() { f 12 CHF= new Money(12, "CHF"); f 14 CHF= new Money(14, "CHF"); } } 13

Tests Refactored public void test. Equals() { assert(!f 12 CHF. equals(null)); assert. Equals(f 12 CHF, f 12 CHF); assert. Equals(f 12 CHF, new Money(12, "CHF")); assert(!f 12 CHF. equals(f 14 CHF)); } public void test. Simple. Add() { Money expected= new Money(26, "CHF"); Money result= f 12 CHF. add(f 14 CHF); assert(expected. equals(result)); } 14

Running of Tests l 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. l JUnit supports two ways of running single tests: – static. – dynamic. 15

16

JUnit Review (1) l In general: development will go much smoother writing tests a little at a time when developing. l When imagine of how the code will work, capture thoughts in a test. l Test code is just like model code in working best if it is factored well. 17

JUnit Review (2) l Keeping old tests running is just as important as making new ones run. l The ideal is to always run all of your tests. l When you are struck by an idea, defer thinking about the implementation. First write the test. Then run it. Then work on the implementation. 18

Testing Practices (1) l Martin Fowler: "Whenever you are tempted to type something into a print statement or a debugger expression, write it as a test instead. ” l 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. 19

Testing Practices (2) l Receive a reasonable return on your testing investment: – During Development. – During Debugging. l Caution: – Once you get them running, make sure they stay running. Ideally, run every test every time you change a method. l Practically, the suite will soon grow too large to run all the time. l 20

Testing Practices (3) Try to optimise your set-up code so you can run all the tests. l Or, l – 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…. 21

References l http: //www. junit. org/ 22

Questions 23