19.2.1. Recognizing Bugs

The earlier a problem is discovered, the better. The process of writing code should therefore be a constant ebb and flow of writing and testing -- write a few lines, export the movie, make sure the lines work as expected, then write a few more lines, export the movie, and so on. Make sure each component of a program works on its own before testing the program as a whole. Try not to get carried away writing a complex body of code without testing it frequently along the way.

Don't assume your movie is perfect just because you can't find any bugs on your own. Always schedule time for external testing by target users, particularly if the code you are delivering is part of a product or a service intended for a client. As described earlier, implement error checking to head off possible problems with incorrect data input. For example, if you write a function that expects an integer argument, you might use the typeof operator to verify that the input parameters are of the correct type. Also test end conditions such as extremely large, small, and negative values, including zero.

Don't underestimate the value of finding the minimum reproducible steps that replicate the problem. These should be the fewest steps that recreate the error reliably. A bug report such as, "I played it for an hour and then it froze" is not very helpful. Useful bug reports include numbered steps such as:

1. Enter 0 for the number of years.

2. Click the Calculate button.

3. The results field shows "NaN" instead of a dollar amount.

19.2.2. Identifying the Source of a Bug

Here, for example, is some code with a bug. It incorrectly sets status to "equal":

var x = 11;
isTen(x);
function isTen(val) {
  if (val = 10) {
    status = "equal";
  }
}

To find out what's wrong with the code, we compare what we think the code should be doing against what it actually is doing, one step at a time:

// This should set x to 11
var x = 11;

// Let's see if it really does
trace(x);     // Yup...this displays: 11

// This should invoke the isTen( ) function
isTen(x);

// Now on to our function
function isTen(val) {
  // Let's make sure our function is being called
  trace("isTen was called");    // Yup...this displays: "isTen was called"

  // Now let's make sure our parameter was passed correctly
  trace("val is " + val);       // Yup...this displays: "val is 11"

Let's pause here for a second. Notice what's happened -- we've made it most of the way through our code and so far everything has worked as expected. Our variable was set correctly; isTen( ) was called and received its argument properly.

TIP

Many errors occur because the code that you think is being executed has never even been reached! We can use trace( ) statements to verify that a particular portion of our code is reached.

By process of elimination, we already know that our code's problem must lie either in the conditional statement if(val = 10) or in the text field assignment status = "equal". We next check our conditional statement by using trace( ) to display the value of its test expression (we're expecting either true or false):

trace(val = 10);

Eureka! The Output window displays 10, not true or false as we had expected.

On closer inspection, we see that the test expression is an assignment statement, not a comparison statement! We forgot an equal sign in our equality comparison operator. The expression if(val = 10) should be if(val == 10).

Obviously, not all bugs are as simple as our conditional statement bug (which is an exceedingly common error), but the approach we used is applicable to most bug hunts: execute a series of trace( ) functions to create a running, step-by-step report on the actual behavior of a movie's code and use the Debugger as explained in the Macromedia documentation.

19.2.3. Common Sources of Bugs

Table 19-1. ActionScript Gotchas

19.2.4. Fixing Bugs

In more involved programs, fixing bugs can be a serious challenge. If a bug is proving difficult to fix, consider the following: