Testing and Debugging Strategies for CSCI-1200 Computer Science II Lab 4, Lab Reports of Data Structures and Algorithms

Testing and debugging strategies for csci-1200 computer science ii lab 4. It emphasizes the importance of writing test code, using cout statements, and debugging tools like the debugger. The document also provides instructions for using visual studio and gdb debuggers. The lab context involves determining which 2d points are in which 2d rectangles.

Typology: Lab Reports

Pre 2010

Uploaded on 08/09/2009

koofers-user-lrp-1
koofers-user-lrp-1 🇺🇸

9 documents

1 / 4

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
CSCI-1200 Computer Science II Fall 2007
Lab 4 Testing and Debugging
Testing and debugging are important steps in programming. Loosely, you can think of testing as verifying
that your program works and debugging as finding and fixing errors once you’ve discovered it does not.
Writing test code is an important (and sometimes tedious) step. Many software libraries have “regression
tests” that run automatically to verify that code is behaving the way it should.Here are four strategies for
testing and debugging:
1. When you write a class, write a separate “driver” main function that calls each member function,
providing input that produces a known, correct result. Output of the actual result or, better yet,
perform automatic comparison between actual and correct result to verify the correctness of a class
and its member functions.
2. Carefully reading the code. In doing so, you must strive to read what the code actually says and
does rather than what you think and hope it will do. Although developing this skill isn’t necessarily
easy, it is important.
3. Judicious use of cout statements to see what the program is actually doing. This is especially useful
for printing the contents of a large data structure or class. It is often hard to visualize large objects
using the debugger (see next item) alone.
4. Using the debugger to (a) step through your program, (b) check the contents of various variables, and
(c) locate floating point exceptions and segmentation violations that cause your program to crash.
Points and Rectangles
The programming context for this lab is the problem of determining what 2D points are in what 2D
rectangles. For rectangles, we will assume they are aligned with the coordinate axes, as shown in Figure ??.
This makes it easy to represent and to test if a point is inside. Our code will store points in rectangles and
determine which points are in which rectangles. This is a toy example of problems that must be addressed
in graphics and robotics.
y
x
(4,3)
(17,9)
(9,3.5)
(8,10)
Figure 1: Example of a rectange aligned with the coordinate axes the only type of rectangle considered
here. The rectangle is specified by its upper right corner point, (17,9), and its lower left corner point,
(4,3). The point (9,3.5) is inside the rectangle, whereas the point (8,10) is outside.
Please download the following 3 files needed for this lab:
http://www.cs.rpi.edu/academics/courses/fall07/cs2/labs/lab03/Point2D.h
http://www.cs.rpi.edu/academics/courses/fall07/cs2/labs/lab03/Rectangle.h
http://www.cs.rpi.edu/academics/courses/fall07/cs2/labs/lab03/Rectangle.cpp
pf3
pf4

Partial preview of the text

Download Testing and Debugging Strategies for CSCI-1200 Computer Science II Lab 4 and more Lab Reports Data Structures and Algorithms in PDF only on Docsity!

CSCI-1200 Computer Science II — Fall 2007

Lab 4 — Testing and Debugging

Testing and debugging are important steps in programming. Loosely, you can think of testing as verifying that your program works and debugging as finding and fixing errors once you’ve discovered it does not. Writing test code is an important (and sometimes tedious) step. Many software libraries have “regression tests” that run automatically to verify that code is behaving the way it should.Here are four strategies for testing and debugging:

  1. When you write a class, write a separate “driver” main function that calls each member function, providing input that produces a known, correct result. Output of the actual result or, better yet, perform automatic comparison between actual and correct result to verify the correctness of a class and its member functions.
  2. Carefully reading the code. In doing so, you must strive to read what the code actually says and does rather than what you think and hope it will do. Although developing this skill isn’t necessarily easy, it is important.
  3. Judicious use of cout statements to see what the program is actually doing. This is especially useful for printing the contents of a large data structure or class. It is often hard to visualize large objects using the debugger (see next item) alone.
  4. Using the debugger to (a) step through your program, (b) check the contents of various variables, and (c) locate floating point exceptions and segmentation violations that cause your program to crash.

Points and Rectangles

The programming context for this lab is the problem of determining what 2D points are in what 2D rectangles. For rectangles, we will assume they are aligned with the coordinate axes, as shown in Figure ??. This makes it easy to represent and to test if a point is inside. Our code will store points in rectangles and determine which points are in which rectangles. This is a toy example of problems that must be addressed in graphics and robotics.

y

x

Figure 1: Example of a rectange aligned with the coordinate axes — the only type of rectangle considered here. The rectangle is specified by its upper right corner point, (17, 9), and its lower left corner point, (4, 3). The point (9, 3 .5) is inside the rectangle, whereas the point (8, 10) is outside.

Please download the following 3 files needed for this lab:

http://www.cs.rpi.edu/academics/courses/fall07/cs2/labs/lab03/Point2D.h http://www.cs.rpi.edu/academics/courses/fall07/cs2/labs/lab03/Rectangle.h http://www.cs.rpi.edu/academics/courses/fall07/cs2/labs/lab03/Rectangle.cpp

Checkpoint 1

Start by creating a project and adding the files Point2D.h, Rectangle.h, and Rectangle.cpp. Examine these files briefly. Point2D.h has a simple, self-contained class for representing point coordinates in two- dimensions. No associated .cpp file is needed because all member functions are defined in the class declaration. Rectangle.h and Rectangle.cpp contain the start to the Rectangle class. They also contain a bug. Please read the code now to see if you can find it. Do not worry if you can not, but do not fix it in the code if you do! To complete this checkpoint: Complete the implementation of the Rectangle.cpp class. Look through Rectangle.h and Rectangle.cpp to determine what functions need to be added. Then, compile these files and remove any compilation errors.

Checkpoint 2

Create a new file called test rectangle.cpp. Create a main function within this file. In the main function, write code to test each of the member functions. For example, write code to create several rectangles, and print their contents right after they are created. Write code that should produce both true and false in the function is point within. If there is non-trivial logic in a function, you should provide multiple inputs in the test code to test as many possible conditions as you can. Write code to add points (or not) to a rectangle. Write code to find what points are contained in both rectangles. To complete this checkpoint: Show a TA your test cases and the error(s) that those test cases reveal in the provided code. After doing this you should be able to spot that there is an error in the provided code (as well as, perhaps, errors in your own code). Even if you know where the bug or bugs occur, please do not fix them yet.

Checkpoint 3

Now, we need to practice using the debugger to find and fix errors. Visual Studio has an associated visual debugger. If you compile with g++ on cygwin, you can use the separate command-line debugger gdb. Other debuggers are available, many of them built on top of gdb. Of special note, gdb may be run from inside of the emacs and xemacs editors. In the following outline, Step 1 is for everyone. Step 2 shows you how to get started, and has separate instructions for using the Visual Studio debugger and using cygwin/g++/gdb. Steps 3 and beyond are written primarily for Visual Studio. Those of you using other debuggers should read the Visual Studio instructions and then adapt them to your debugger. Specific pointers to gdb commands are provided at the end of each item. You may use your internet connection to read reference material specific to your debugger & development environment.

  1. Run your program that has tests for the basic member functions. Even though the program will compile and run, it will not give the correct output. You may be suspicious about a place in your code where the error occurs. It is time to start the debugger.
  2. Getting started:
    • Getting started with the Visual Studio debugger: Begin by Setting a breakpoint. In the source code, go to the file where the error might have originated. Select Debug -> New Breakpoint. Four options will be presented. You can set a breakpoint based on the program entering a func- tion, at specific point in a file, at a memory address, or when a specific data condition is met. Click File and you will notice that the current line number is displayed. Click OK. A breakpoint is now set. Your program will halt when execution reaches this location in the code (when run using the debugger). Note, that you can set this simplest Breakpoint (with standard options) not only using this menu, but also by right clicking at a particular line (then Insert Breakpoint), or even more quickly clicking on a grey bar along left side of your window.
  1. Program flow: In Visual studio, you will find another set of debugging windows in the second panel. These are “Call Stack”, “Breakpoints”, “Command Window”, and “Output”. The Call Stack displays the current execution path (in terms of function calls). Click on different entries in the call stack and different code will be displayed. Be sure to get back to the code for Rectangle. You can tell from the position of the yellow arrow. Breakpoints lists all breakpoints in your program. Output window shows status of various features in the development environment and we won’t use it much in this class. Command Window is very useful and powerful. It allows you to evaluate expressions, execute statements, print variable values, and sometimes even change them. It operates in two modes, we will use only Immediate mode (you should see the tab name as “Command Window
    • Immediate”, if you do not, type immed). In gdb, you can use the command backtrace to show the contents of the call stack. This is particularly important if your program crashes. Unfortunately, the crash often occurs inside C++ library code. Therefore, when you look at the call stack the first few functions listed may not be your code. Find the function on the stack that is the first one (nearest to the top of the stack) that is your code. By typing frame N, where N is the index of function on the stack, you can examine your code and variables and you can see the line number in your code that caused the crash.
  2. Command Window In Visual Studio, type ?m_upper_right int the command window. You should see complete report about this variable. Now change the +x+ coordinate of the upper right corner by typing m_upper_right.m_x=2. Again, check the status of the variable. When you type ?m_points_contained, you get report about your vector variable. You will see three pointers with their values; these are pointer to an array which is internal representation of the vector. Type ?m_points_contained._Myfirst and you will find out about the first element (Point2D). To see the second, type ?m_points_contained._Myfirst[1], and so forth. In gdb many of these options are handled through the print and display commands.
  3. Now, step through the execution one line at a line. Look at the source code, the console, and the watch window. You should see the error pretty soon. Use the Watch window to find the bug in the program. Hint: You can even display one coordinate of your rectangle. When you have found it, show a TA how you found it using the debugger. In Visual Studio, have your Watch window visible and also show the contents of your Command Window where you tried examples above (enlarge the windows to take about half of your laptop screen). Be ready to answer questions about the purpose of the other debugging windows.
  4. Breakpoint on Variable Change: The last powerful debugger feature you will find out about today is variable monitoring. Create an instance of Point2D in your main function and change the coordinates using Set function. Now monitor the change of this point using the debugger. In Visual Studio, select Debug -> New Breakpoint and choose the Data tab. In Variable field, type pt.m_x, pt is my point in this case. Context is to tell the debugger, where can the variable be found. The syntax is {[function],[source],[module]}, in our case, it is enough if we fill in {,test_rectangle.cpp,}. Hit OK and run the debugger. In gdb, you can use the command watch to halt the program when a variable or expression changes. To complete this checkpoint: In addition to the debugging you demonstrated in Step 7, show a TA that your program successfully stopped when the variable was changed. Your TA may also ask you questions about the other steps in debugging.

Please note that this lab has only given you a brief introduction to debugging. You will learn much more through extensive practice. When you visit the TAs or instructor in office hours to ask for help in debugging your assignments, we will constantly be asking you to show us how you have attempted to find the problem on your own. This will include combinations of the four steps listed at the start of the lab.