1. 1 Debugging and Testing Overview Defensive Programming The goal is to prevent failures Debugging The goal is to find cause of failures and fix it Testing The goal is to discover failures The goal is to verify the requirements

2. 2 Defensive Programming Anticipate potential problems and design and code the system so that they are avoided or at least detected as early as possible. Defensive design – avoid bugs Defensive coding – localize problems

3. 3 Defensive Design Make your design simple Use encapsulation (decoupling of classes) – any class should not depend on any other classes on the same level Design with error in mind – ask a lot of “what if” questions

4. 4 Design Review Show design to somebody else: peers, management, outside consultants Present design, it makes more details about the design explicit and can uncover many problems Implicit assumptions are uncovered

5. 5 Make assumptions explicit Define pre- and post-conditions – – assumptions about input parameters and the state of the object when the method is invoked – output parameters and state of the object upon return Make them part of the documentation and code itself

6. 6 Specifying pre/post-conditions Establish the bounds of the input parameters Specify the condition of the object before and after the function execution Specify the changes, if any, to the input parameters Can be done formally (predicate logic) or informally (in words) in documentation

7. 7 Example Function Search(array[size], size, key) Precondition: array is not empty, it is of size ‘size’ Postcondition: if key is in array, Search() returns index of key, otherwise -1

8. 8 Defensive Coding Be suspicious: – Public methods should check that the values of incoming parameters are within the expected ranges – Check that called methods return valid values – Check for error conditions returned by called methods – Check intermediate values/data if it can be done inexpensively

9. 9 Defensive Coding Ensure that data is initialized to meaningful values Do code reviews Use assertions – a means to implement pre and postconditions in the code Use exceptions – define special classes for exceptions, use them to return error conditions that should be handled non-locally Declare methods to throw exceptions

10. 10 Evolutionary Programming Compile your code often Test your code before you implement everything Evolve your program by writing modules and using stubs

11. 11 Debugging Use a symbolic debugger (dbx on Unix) If a memory checking tool is available, learn to use it to locate memory problems THINK Keep an error log Whenever you discover an error, check for the same error in other parts of the program

12. 12 Error log When was the error made? Who made the error? What was done incorrectly? How could the error have been prevented? How was the error found? How could the error have been detected earlier and with less work?

13. 13 Error repair Fixes are not always correct Fixing one problem often causes several other problems Fix the problem and the symptom

14. 14 Testing Software testing is a critical element of software quality assurance and represents the ultimate review of specification, design, and coding Testing should be carried out throughout the life-cycle: – Static: code inspections, walkthroughs – Dynamic: module, integration, system testing

15. 15 Software Testing Myths If we were really good programmers, there would be no bugs to catch Testing implies an admission of failure Testing is a punishment for our errors All we need to do is: – Concentrate – Use OO methods – Use a good programming language

16. 16 Software Testing Reality Humans make mistakes, especially when creating complex artifacts Even good programs have 1-3 bugs per 100 lines of code People who claim that they write bug- free code probably haven’t programmed much

17. 17 Goals of Testing Discover and prevent bugs, not show that program works The act of designing tests is one of the best bug preventers known Even tests are sometimes buggy The real goal of testing is to reduce the risk of failure to an acceptable level

18. 18 Test types – another view System Test The program is treated as a black box System requirements are tested against the black box Integration Test Different components are integrated together Verify that different components within the system work fine Unit Test Small units of the program are subjected to testing. Test each function Typically done as you write code

19. 19 100 % Bug Free Software ? NO. Complete testing is NOT possible for non-trivial software both practically and theoretically Assuming a program only has one input of 10 characters, it would require 2^ 80 tests, which at 1microsecond/test would take more than twice the current estimated age of the universe

20. 20 Test coverage Statement coverage: each statement is executed at least once Decision coverage: every branch is taken at least once Test for invalid, unexpected conditions Test for boundary conditions Use varied tests

21. 21 Regression testing Every time new code is introduced/bugs are fixed, all old test cases should still produce the correct output Every time a new test case uncovers a bug, add it to your suit of test cases