1. CSC 213 – Large Scale Programming

2. Why Do We Test?

3. But the Problem Is…

4. Can We Get Best Of Both?

6. Testing To The Rescue  Before we start coding, write solid set of tests  Best, worst, & average cases examined in tests  Includes tests for all possible boundary conditions  Tests drive the code & set pace of the coding  Code only written to be good enough to pass tests  Debugging simplified using the simple failed cases  Once system can pass all tests, we’re golden

7. Testing To The Rescue  Before we start coding, write solid set of tests  Best, worst, & average cases examined in tests  Includes tests for all possible boundary conditions  Tests drive the code & set pace of the coding  Code only written to be good enough to pass tests  Debugging simplified using the simple failed cases  Once system can pass all tests, we’re golden

8. Testing To The Rescue  Before we start coding, write solid set of tests  Best, worst, & average cases examined in tests  Includes tests for all possible boundary conditions  Tests drive the code & set pace of the coding  Code only written to be good enough to pass tests  Debugging simplified using the simple failed cases  Once system can pass all tests, we’re golden

9. Oops…  Design we created has lots of side effects  Results printed out at the end of void methods  Other methods just update values of object’s fields  Add special methods that allow field access  Not a big deal & needed to test affect on fields' values

10. OOPS…  Stuck with BIG issue: how to check I/O correct?  How to test screen to verify warning are printed?  How to insure file has correct values before & after?

11. OOPS…  Stuck with BIG issue: how to check I/O correct?  How to test screen to verify warning are printed?  How to insure file has correct values before & after?  Cannot skip tests since correctness important  Always want to be correct, but cannot test online

12. OOPS…  Stuck with BIG issue: how to check I/O correct?  How to test screen to verify warning are printed?  How to insure file has correct values before & after?  Cannot skip tests since correctness important  Always want to be correct, but cannot test online And it monitors a nuclear reactor

14. Laziness Depends on Design  Well-planned design makes testable methods  Testable methods leads to good tests  Good tests leads to easy coding & debugging  Easy coding & debugging leads to free time  Free time leads to laziness

15. Design Methods For Testing  Start by defining method for each calculation  Method returns result once it is calculated  As needed, create other methods to output results  Easy to test & debug methods with observable results

16. Design Methods For Testing  Start by defining method for each calculation  Method returns result once it is calculated  As needed, create other methods to output results  Easy to test & debug methods with observable results versus

17. Mock Objects To Win  Some things just cannot be tested with JUnit Failed nuclear plant tests a bit of a problem  Some times its impossible to access or use classes  File or network I/O required, but cannot test offline  These situations leave limited options  Whine about it being unfair  Leave code untested and say "oops" a lot  Prove correctness mathematically  Create stand-ins called mock objects

18. Getting Ready for Mocks  Use interfaces in place of hard-to-use classes  Interface defines minimum number of methods  Update old class to implement this interface  Must modify code when hard-to-use class alloc'd  Pass instance to method & eliminate new command  If instance was field, set using constructor's parameter

19. Original Example public class ThreeMileIsland { private NuclearReactor reactor; public ThreeMileIsland() { reactor = new NuclearReactor("SNPP"); } public boolean checkForBreach() { if (!reactor.withinLimits()) { return reactor.alarmSounding(); } return false; } }

20. New Interface public interface NRInterface { public boolean withinLimits(); public boolean alarmSounding(); } public class ThreeMileIsland { // More code went here public boolean checkForBreach() { if (!reactor.withinLimits()) { return reactor.alarmSounding(); } return false; } }

21. Rewrite From This… public class ThreeMileIsland { private NuclearReactor reactor; public ThreeMileIsland() { reactor = new NuclearReactor("SNPP"); } public boolean checkForBreach() { if (!reactor.withinLimits()) { return reactor.alarmSounding(); } return false; } }

22. Rewrite From This… …To This public class ThreeMileIsland { private NRInterface reactor; public ThreeMileIsland(NRInterface nm) { reactor = nm; } public boolean checkForBreach() { if (!reactor.withinLimits()) { return reactor.alarmSounding(); } return false; } }

23. Why We Write Mock Classes!

24. Create Mock Class  Write classes needed to test code fully  Testing ThreeMileIsland not NuclearReactor  ONLY purpose is testing  ONLY purpose is testing other classes code  May hard-code values; write as simply as possible  Store parameters in Sequence s to check calls correct  Do not use files or network, mock to avoid these needs  Duct tape & mock classes are similar  Useful & pretty, but not the real thing

25. Writing Mock Class public interface NRInterface { public boolean withinLimits(); public boolean alarmSounding(); } public class MeltdownMock implements NRInterface{ public boolean withinLimits() { return false; } public boolean alarmSounding() { return true; } }

26. Using Mock Class

27. Writing Mock Class public class MeltdownMock implements NRInterface { public boolean withinLimits() { return false; } public boolean alarmSounding() { return true; } } @Test public void testTMI() { NRInterface mltdn = new MeltdownMock(); ThreeMileIsland tmi = new ThreeMileIsland(mltdn); assertTrue(tmi.checkForBreach()); }

28. Mock Class Coding Review  Use interfaces in place of hard-to-use classes  Interface defines minimum number of methods  Update old class to implement this interface  Must modify code when hard-to-use class alloc'd  Pass instance to method & eliminate new command  If instance was field, set using constructor's parameter  Test original using specially written mock classes  Mock classes should be simple, often return a constant  Not testing mocking, but if class can handle its result

29. Testing Printing To Screen  Java already thought of this & created solution  Only need to set static field in System class  System.setOut(PrintStream) does this for us  Instance passed as parameter will be sent all output  No new classes required for this to work  Can add code to method run before each test  @Before method needed to contain this code

30. Writing Code to Test Output

33. For Next Lecture  Next weekly assignment available online  Due as usual tomorrow at 5PM  Give me notes on reading to delay this due date  Reading on event-driven programming  How to code if we do not know what will happen?  What error is found most starting GUI programs?  How can I make my code finish within my lifetime?  (Design notes for ActionListener okay for extension)