Chapter 19. Testing and Debugging Your Animation

The odds are against you. When you're designing an animation and writing ActionScript code, there may be several ways to do it and have it come out right. Unfortunately, there are many more ways you can do it wrong. Maybe you chose a motion tween when you meant to choose a shape tween, or you added content to a frame instead of a keyframe. In ActionScript, a tiny error like using a capital letter in the wrong place or misplaced semicolon can ruin everything. The more complex your project is, the more errors you're likely to encounter.

The only way to find—and fix—your mistakes before your audience sees them is to test and debug your projects. Yes, troubleshooting can be tedious, time-consuming, and not nearly as much fun as designing and creating a brilliant animation. But if you approach troubleshooting as solving a puzzle or a mystery, it can be fun. Furthermore, Flash Professional CS5 comes with some pretty powerful testing and debugging tools to you help you find and squash those bugs.

Throughout this book, you've seen examples of testing an animation using the Control→Test Movie option (for example, Figure 19-5). This chapter expands on that simple test option, plus it shows you how to test animation playback at a variety of connection speeds. And if you've added ActionScript to your animation, this chapter shows you how to unsnarl uncooperative ActionScript code using Flash's debugging tools.

Testing Strategies

All your audience ever sees is the finished product, not your intentions. So no matter how sophisticated your animation or how cleverly constructed your ActionScript code, if you don't test your animation and make sure it works the way you want it to, all your hard work will have been in vain.

The following section shows you how to prepare for testing from the very beginning by following good Flash development policies. Also, you'll find out the differences between testing on the stage and testing in Flash Player, along with tips for testing your animation in a web browser.

Planning Ahead

The more complex your animation, the more you need a thorough plan for testing it. Few of the guidelines in the next two sections are specific to testing in Flash. Instead, they're tried-and-true suggestions culled from all walks of programming life. Following them pays off in higher-quality animations and reduced time spent chasing bugs.

Ideally, you should begin thinking about testing before you've created a single frame of your animation. Here are some pre-animation strategies that pay off big:

Separate potentially troublesome elements

ActionScript actions are very powerful, but they can also cause a lot of grief. Get into the habit of putting them into a separate layer named "actions," at the top of your list of layers, so that you'll always know where to find it. Putting all your labels into a separate layer (named "labels") is a good idea, too. With sounds, you may be able to put them in a single layer, or a sounds folder.

Reuse as much as possible

Instead of cutting and pasting an image or a series of frames, create a symbol and reuse it. That way, if a bug raises its ugly head, you'll have fewer places to go hunting. You can cut down on bugs by reusing ActionScript code, too. Instead of attaching four similar ActionScript actions to four different frames or buttons, create a single ActionScript method or function (see Functions and Methods Put the Action in ActionScript) and call it four times.

Be generous with comments

Before you know it, you'll forget which layers contain which images, why you added certain actions to certain objects, or even why you ordered your ActionScript statements the way you did. In addition to adding descriptive comments to all the actions you create, get in the habit of adding an overall comment to the first frame of your animation. Make it as long as you want, and be sure to mention your name, the date, and anything else pertinent you can think of. You create a comment in ActionScript two different ways, as shown below.

// This is an example of a single-line ActionScript comment.

/* This type of ActionScript comment can span more than one line. All you
have to remember is to begin your multiline comment with a slash-asterisk
and end it with an asterisk-slash, as you see here. */

Stick with consistent names

Referring to a background image in one animation as "bg," in another animation as "back_ground," and in still another as "Background" is just asking for trouble. Even if you don't have trouble remembering which is which, odds are your office teammates will—and referring to an incorrectly spelled variable in ActionScript causes your animation to misbehave quietly. In other words, type Backgruond instead of Background, and Flash may not pop up an error message; your animation just looks or acts odd for no apparent reason. Devise a naming convention you're comfortable with and stick with it. For example, you might decide always to use uppercase, lowercase, or mixed case. You might decide always to spell words out, or always to abbreviate them the same way. The particulars don't matter as much as your consistency in applying them. Keep in mind that capitalization counts. Because Flash is case-sensitive, it treats background, Background, and BACKGROUND as three different names.

Tip

If you're looking for a guide with coding conventions, Adobe developed one for Flash's sibling Flex. The guide covers naming conventions, abbreviations, acronyms, and several other topics of interest to those writing code in ActionScript 3.0. You can find the online guide at http://opensource.adobe.com/wiki/display/flexsdk/Coding+Conventions#CodingConventions-Abbreviations.

Techniques for Better Testing

The following strategies are crucial if you're creating complex animations as part of a development team. But they're also helpful if it's just you creating a short, simple animation all by your lonesome.

• Test early, test often. Don't wait until you've attached actions to 16 different objects to begin testing. Test the first action, and then test each additional action as you go along. This iterative approach helps you identify problems while they're still small and easy to pinpoint.

• Test everything. Instead of assuming the best-case scenario, see what happens when you access your animation over a slow connection or using an older version of Flash Player. What happens when you type the wrong kind of data into an input text field or click buttons in the wrong order? (Believe this: Your audience will do all of these things, and more.)

• Test on different computers. It's very important to test on a computer other than the one that writes the code. For example, an alien computer may have different fonts installed or a different version of Flash Player or some other support file. Use as much variety as possible in testing. Use Macs and PCs. Use old clunkers and the latest, greatest state-of-the-art machine you can get your hands on. Then test on a underpowered netbook.

• Test in different web browsers. If your animation is going to be viewed over the Internet, try it out in different browsers. These days, Microsoft's Internet Explorer, Apple's Safari, Firefox, and Google's Chrome are the most widely used browsers. It's best to test in each browser. Each of these browsers has several versions in use. For the fewest surprises and complaints, test in the last two or three available versions.

• Test blind. In other words, let someone who's unfamiliar with how your animation is supposed to work test it. In programming circles, this type of testing is known as usability testing, and it can flush out problems you never dreamed existed.

• Test in "real world" mode. Begin your testing in the Flash authoring environment, as you see on Testing on the Stage, but don't end there. Always test your animation in a production environment before you go live. For example, if you're planning to publish your animation to a website, upload your files (including your .swf file and any external files your animation depends on) to a web server, and then test it there, using a computer running the operating system, connection speed, browser, and Flash Player plug-in version you expect your audience to be running. (Sure, transferring a few files isn't supposed to make a difference—but it often does.) Chapter 20 covers publishing to the Web, as well as other publishing options.

Up To Speed: Testing on the Stage vs. Testing in Flash Player

Flash gives you two options for testing your animation: on the stage and in the built-in Flash Player. Testing on the stage is faster, and it's good for checking your work as you go along, but in order to try out your animation exactly as your audience will see it, you have to eventually fire it up in Flash Player. Here's some more advice on when to choose each.

Testing on the stage is the quick and easy option, using the Controller toolbar and the associated menu options (Control→Play, Control→Stop, Control→Rewind, Control→Step Forward One Frame, Control→Step Backward One Frame, and Control→Go to End). Testing on the stage is quicker than testing in Flash Player, because you don't have to wait for Flash to compile (export) your Flash document and then load it into the Player. Instead, when you test on the stage, Flash immediately resets the playhead and moves it along the timeline frame by frame. For simple animations, testing on the stage can be easier as well as quicker than testing in Flash Player because you can position the Controller toolbar on your workspace where it's handy—no need to wait for Flash Player's menu options to appear.

The downside to testing on the stage is that it doesn't always test what you think it's testing. For example, if you test a frame containing a movie clip instance, you don't see the movie clip playing; you have to switch to symbol editing mode and then test the symbol there to see the movie clip in action. And if your animation contains a button instance and you forget to turn on the checkbox next to Control→Enable Simple Buttons, the button doesn't work on the stage—even though it may work perfectly well when you test it in Flash Player.

Testing in the built-in Flash Player (Control→Test Movie→in Flash Professional, and Control→Test Scene) is the more accurate option. When you test an animation by selecting Control→Test Movie→in Flash Professional or Control→Test Scene, Flash generates an .swf file. For example, if you're testing a Flash document named myDocument.fla, Flash generates a file called myDocument.swf (or myDocument_myScene.swf, if you're testing a scene) and automatically loads it into a Flash Player test window that's part and parcel of the Flash development environment. This option usually shows you exactly what your audience will see, not counting computer hardware and connection differences (Testing Download Time).