Debugging and (Automated) Testing

const int n=10;
int sum=0;
for (int i=0;i<n;i++)
	for (int j=0;j<n;i++)
		sum+=i*j;
return sum;

(Try this in NetRun now!)

class llnode {
public:
	int data;
	llnode *next;
	llnode(int v,llnode *n) {data=v; next=n;}
};
int total(llnode *cur,int sum)
{
	sum+=cur->data;
	return total(cur->next,sum);
}
llnode *make_list(void) {
	int x;
	if (cin>>x) { return new llnode(x,make_list()); }
	else { return NULL; }
}
int foo(void) {
	llnode *cur=make_list();
	return total(cur,0);
}

(Try this in NetRun now!)

int x=0;
cin>>x;
return x;

(Try this in NetRun now!)

Debugging Strategies

• Debug statements, like "cout" or file output statements to a log file.  This is probably overused, but it's a very powerful technique, because scrolling backward from the point of the crash takes you backward in time, letting you hone in on the error!
• Using a debugger.  The point of the crash is somewhat useful about half the time, although like in an airplane accident, the other half of the time the crash itself is usually several minutes after the real problem happened.  For example, it's common to corrupt memory, or bork some internal data structure of a library, and still have the program lurch along for quite a while, as things go more and more wrong, until finally something comes totally unglued and crashes.  Another problem with debuggers is Heisenbugs: errors that disappear when you look at them in a debugger.  Debuggers change the timing and speed of the code, which can affect a variety things in strange ways.
  

Testing Strategies