Lecture 7: Debugging and Testing

Background Material

• C, C++, Java, Perl
• Think about your programming experience. What types of bugs have you encountered? How did you find them? Which bugs were particularly difficult to find. How do you test your code? Do you test while you are developing your code or do you wait until you are done? How do you determine your test cases?

Reading

• Chapters 5 and 6 of the text.
• GDB, gnu's debugger

Topics

• Debugging
  1. Debuggers (gdb)
  2. Effective use of print statements
  3. Stack trace
  4. Use of assertions.
  5. Look for familiar patterns.
  6. Examine the most recent changes
  7. Don't make the same mistake twice
  8. Debug it now, not later
  9. Think before debugging (what do you expect to happen? each test should aim at a definitive outcome that confirms or denies a specific hypothesis).
  10. Write trivial programs to test hypotheses or confirm your understanding of how something works.
  11. Divide and Conquer (to look for problem in code and to generate small inputs that cause problems).
  12. Display output to localize your search.
  13. Write self-checking code.
  14. Write a log file.
  15. Draw a picture.
  16. Use tools (diff, makes, memory leaks, version control).
  17. Keep records.
• Testing
  1. Test code at its boundaries.
  2. Test pre- and post-conditions (use assertions).
  3. Program defensively.
  4. Check error returns.
  5. Test Incrementally.
  6. Test simple parts first.
  7. Know what output to expect.
  8. Compare independent implementations.
  9. Measure test coverage.
  10. Automate testing (regression testing, stress tests).
  11. Try to force errors to happen (cause memory allocator to fail)

Lecture Notes

• None for this lecture.

Programs

• bug1.c - common bug in C.
• bug2.c - common bug in C.
• A program that causes a segmentation violation sorti.c. To generate the error run sorti with the input in" This program uses qsort to sort an array of integers. The error comes from passing qsort a function to compare strings rather than integers. Why can't the compiler catch this? You can uncover the problem by producing looking at a stack trace from when the program crashed (see the lab on how to do this). What happens if you are using qsort to sort strings and accidently pass the integer comparison function?
• avg.c - example use of assert.
• quicksortbug.c - simple bug in the quicksort program from the text - how would you find it? What assertions could you put into the code to check that the algorithm was implemented properly?

Resources

• Materials on different languages: perl, C, C++ (STL), Java
• Introduction to Perl perl.ppt and perl.pdf

Lab

• Debugging Lab

Assignments

• Assignment 3