Testing in NetBeans

1. Testing in NetBeans

2. Testing • The ideal test: • When the test is passed, the product is ready for delivery! • Ideal – but (almost) impossible • Number of test cases is often very large • How does one test a GUI? • Is functional correctness all that matters? SWC

3. Testing SWC

4. Unit testing • A Unit Test is aimed at testing a well-defined code module, in Java usually a single class • Unit tests are at the functional level • Define test cases in terms of input to class methods (public and private) • Define the expected output for each case • Run the test • Compare expected and actual output SWC

5. Unit testing • NetBeans can create a unit test framework (or ”test harness”) for a project • Relies on a Java framework called JUnit (see www.junit.org) • We also used JUnit in BlueJ SWC

6. Unit testing in NetBeans • Consider our ”classic” BankAccount class, with three methods: • deposit • withdraw • getbalance • Having created the class, we can now create a unit test for the class SWC

7. Unit testing in NetBeans SWC

8. Unit testing in NetBeans SWC

9. Unit testing in NetBeans SWC

10. Unit testing in NetBeans • There are quite a lot of options to choose from when generating a test class… • For now, just leave them as-is • When pressing Finish, a unit test class is generated for us, called BankAccountTest (just choose ”Junit 4.x”) • The test class is placed under Test Packages SWC

11. Unit testing in NetBeans • The generated test class does look a bit complex (remember we chose all options) • However, we are free to edit it! • Remove whatever you do not need • NetBeans can only generate a ”skeleton” for the test class – we must complete it SWC

12. Unit testing in NetBeans @BeforeClass public static void setUpClass() throws Exception { } @AfterClass public static void tearDownClass() throws Exception { } SWC

13. Unit testing in NetBeans • The two methods setUpClass and tearDownclass allows us to include any actions needed before and after running all the test class methods, respectively • Dependencies to other classes • Database connection • Etc. • Is often not used – then delete it! SWC

14. Unit testing in NetBeans @Before public void setUp() { } @After public void tearDown() { } SWC

15. Unit testing in NetBeans • The two methods setUp and tearDown allows us to include any actions needed before and after running each of the test class methods, respectively • Initialising/resetting variable values • Cleaning up data structures • Etc. • Is often not used – then delete it! SWC

16. Unit testing in NetBeans @Test public void testGetBalance() { System.out.println("getBalance"); BankAccount instance = new BankAccount(); int expResult = 0; int result = instance.getBalance(); assertEquals(expResult, result); // TODO review the generated test code and // remove the default call to fail. fail("The test case is a prototype."); } SWC

17. Unit testing in NetBeans • Notice that a test method does not return a value (true/false) • Instead, so-called assertions are used during the test • An assertion can succeed or fail • A failed assertion throws an exception, and the test case is considered failed SWC

18. Unit testing in NetBeans • Examples of assertions: • assertEquals(expectedValue, ActualValue) • assertTrue(condition) • assertFalse(condition) • assertNotNull(object) • assertNull(object) • assertSame(object, object) • assertNotSame(object, object) • fail() // ALWAYS fails SWC

19. Unit testing in NetBeans • If you inspect the generated test code, you will find that it is not very useful • We must – almost always – implement the body of the test methods ourselves • We are free to add more test methods than those initially generated – the test framework will run them automatically SWC

20. Unit testing in NetBeans • Once the test methods have been defined properly, we can run the test • Choose Run | Test Project, or just press Alt + F6 • Result of test is displayed in the output window, with indicative colors SWC

21. Unit testing in NetBeans SWC

22. Unit testing in NetBeans SWC

23. Unit testing considerations • In the ideal scenario, all units tests should be completely self-contained • Testing of a particular class should not depend on other classes • Testing of a particular method should not depend on other methods • Isolates cause of failed tests SWC

24. @Test public void testDeposit() { int b = theAcc.getBalance(); theAcc.deposit(500); int a = theAcc.getBalance(); int diff = a – b; assertEquals(diff, 500); } Unit testing considerations SWC

25. Unit testing considerations You are wrong! • Suppose now that testDeposit fails • Which method in BankAccount contains an error…? • Is it deposit, or getBalance...? No, you are wrong! SWC

26. @test public void testCubeVolume() { int volume = theCube.getVolume(); int expVolume = theMathLib.calcCube(theCube.getSide()); assertEquals(volume, expVolume); } Unit testing considerations Cube getSide getVolume MathLibrary calcCube … SWC

27. Unit testing considerations You are wrong, again! • Suppose now that testCubeVolume fails • Which class contains an error…? • Is it Cube or MathLibrary…? No, you are wrong again! SWC

28. Unit testing considerations • Testing one functionality often assumes that some other functionality already works correctly… • This is quite hard to avoid in practice • A rigorous approach is to use so-called test stubs SWC

29. Unit testing considerations • A test stub is a ”simulation” of the behavior of a real class or method • (Martin Fowler): Test stubs provide canned answers to calls made during the test, usually not responding at all to anything outside what's programmed in for the test SWC

30. Unit testing considerations • Making a test stub • Write the test, calling any external methods that are needed • Substitute all calls to external methods with calls to stub methods (Proxy…?) • Implement the stubs as returning the desired answer without any calculation SWC

31. @Test public void testCubeVolume() { int volume = theCube.getVolume(); int expVolume = theMathLibStub.calcCube(theCube.getSide()); assertEquals(volume, expVolume); } ... // Code in MathLibraryStub // Only called with input = 8 in test publicint calcCube(int input) { return 512; } Unit testing considerations SWC

32. Unit testing considerations • Creating a test using stubs consequently can be done – but is quite labor-intensive • More pragmatic approach is to use a bottom-up approach • Test basic methods/classes first (methods/classes that do not use other methods/classes) • When basic methods/classes work, test methods/classes that only use basic methods/classes • And so on (dependency tree) SWC

33. Testing – final remarks • We can (almost) never expect to create a completely covering test  • Testing is about raising confidence in the correctness of the program • Always a compromise between level of confidence and required effort SWC

34. Testing – final remarks Confidence Effort Student assignment Commer-cial word processor Space Shuttle software SWC

35. Testing – final remarks • Further reading: • JUnit test in NetBeans http://www.netbeans.org/kb/docs/java/junit-intro.html • More about Junit in general www.junit.org • …and the Net contains a lot of material about test in general! SWC