General Testing and Debugging

As this chapter has already pointed out, you will want to use extensive error handling to take care of any errors that occur during the execution of your code. However, an even better idea would be to properly test your code before you send it out. Good testing is a vital skill, and one that is rarely discussed in introductory C++ books.

There are three types of data you should test, and there are three types of testing you should do. The three types of data are: valid data, invalid data, and extreme data. The first, valid data, is simple. Type in the sort of data that your program is expecting and see whether it works. That is something most programmers, even beginners, address. The second area, invalid data, is sometimes overlooked. What happens if your program asks for an integer yet the user types in “A”? And, finally, you should check what happens with extreme data. If you ask the user to enter their age, and they enter 300 instead of 30, does your program just blindly go along with that clearly fallacious input? Or is your program smart enough to warn the user that their input is simply not possible? The discussion of data validation, later in this chapter, will show you how to accomplish this. For now, remember, when testing your program, to make certain that you test with all three types of data.

Now that you know what type of data to test, we can discuss how to test. There are three types of testing: unit testing, stress testing, and beta testing. Unit testing literally means to test the software on a single unit, normally your own PC. You would test all three types of data, but you would simply test them on your own machine. Stress testing involves pushing the program to its limits. If it is a multiuser program, then put a large number of users on it simultaneously. If its designed to handle 50 calculations per hour, then push it to at least 50 (actually going 10% beyond 50 would be even better). And, finally, we have beta testing. This involves simply getting your program to a handful of users and getting their feedback.

A lot of software today is inadequately tested. The news is filled with reports of software flaws, some causing significant problems. It is absolutely vital that you thoroughly test your software.

As you test your software you may find flaws. These are usually referred to in the industry as “bugs.” It is amazing how many programmers are not very skilled at locating such bugs. Most programmers can easily fix a problem once it is found, but have difficulty finding it. There are some simple techniques you can use to find bugs in your programs.

One technique is to selectively comment your code. If the compiler tells you that there is an error, then simply comment out half your code and see if you still get the error. If you do still receive the error, add one half of the remaining code to your commented section and try to compile again. If you do not still receive the error, remove the comments from the one half you already commented. The following code has an error and generates a compiler error message syntax error : missing ; before identifier cout. Obviously, there is a problem with a missing semicolon before a cout statement, but which one? You could reread them all, and in a small program, that’s probably the best thing to do. In a large program, however, doing this will not work. Let’s take the section that has cout statements (the main function) and comment out half of it and see what happens.

// Include statements #include <iostream> using namespace std;   float cube_number(float num); float square_number(float num); int main() {   float number;   float number3;   cout << "Please enter a number \n";   cin >> number;   if (number > 0 && number < 100)   { number3 = cube_number(number); cout << number << "cubed is "<< number3;   }// end of if   else   { number3 = square_number(number) cout << number << "square is "<< number3;   }// end of else       if (number3 <10000 || number3 ==2)   { number3 = square_number(number3);  cout << number3 << "squared is "<< number3;   }// end of second if  return 0;  }// end of main float square_number(float num) {  float answer;  answer = num * num;  return answer; } float cube_number(float num) {  float answer;  answer = num * num * num;  return answer; }

To find that error, comment out half the code and then try to compile again.

int main() {   float number;   float number3;   cout << "Please enter a number \n";   cin >> number;       if (number > 0 && number < 100)   { number3 = cube_number(number); cout << number << "cubed is "<< number3;   }// end of if /* BEGIN COMMENTING OUT CODE FOR TESTING      else   { number3 = square_number(number) cout << number << "square is "<< number3;    }// end of else    if (number3 <10000 || number3 ==2)    { number3 = square_number(number3); cout << number3 << "squared is "<< number3;    }// end of second if    END COMMENTING OUT CODE FOR TESTING */  return 1;  }// end of main

After compiling the code again, no errors are found. The problem, therefore, is in the section that was commented out. This technique can help you to drastically shrink the area you have to examine for a flaw. When writing larger programs, this will be helpful.

It is also important to look at the area surrounding an error. If you use one of the commercial IDEs such as Microsoft Visual or Borland C++ Builder, then the IDE can let you go directly to where the error is generated. However, sometimes the error is actually caused by code prior to where the error shows up. For example, a missing semicolon at the end of one line will cause the compiler to try to execute the next line as if it were part of that line. Thus, a good rule of thumb is to check the preceding four or five lines of code. Also remember the most common errors are the following.

1. Spelling

2. Missing semicolons

3. Forgetting to close a bracket around a block of code

4. Forgetting that C++ is case-sensitive

Always look for these errors. In fact, whenever you finish writing a significant section of code, it’s a good idea to give it a quick read-through to search for these types of errors.

Another commonly used technique is to use cout statements at various locations in your code to print-out the value of certain variables. If you have a calculation that is not performing correctly, then this may be your best debugging technique. If you can see the values of the pertinent variables at each stage in the process you will be able to identify precisely where the problem occurs.

These are just a few “tricks of the trade” that might help you in debugging your applications. The important thing to remember about these techniques, and others, is that they are for debugging, not producing code. When you are finished debugging and testing, make sure you uncomment any code blocks that you commented out, and remove any cout statements that you put in for debugging purposes.