Section 13.1. Testing Strategies

13.1. 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 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.

13.1.1. 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 preanimation strategies that pay off big:

13.1.1.1. 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, either at the top of your list of layers or at the bottom, so that you'll always know where to find it. Putting all your sounds into a separate layer (named sounds) is a good idea, too.

13.1.1.2. Reuse as much as possible

Instead of cutting and pasting an image or a series of frames, create a graphic 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 function and call it four times.

13.1.1.3. 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 of the actions you create (there's an example at the end of this chapter, in Figure 13-19), 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 multi-line comment with a slash-asterisk and end it with an asterisk-slash, as you see here. */ 

13.1.1.4. 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 willand referring to an incorrectly spelled variable in ActionScript causes your animation to misbehave quietly . In other words, type Background instead of Background , and Flash doesn't 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 so much as your consistency in applying them.

---

Note: Capitalization counts. Because Flash is case-sensitive, it treats background, Background, and BACKGROUND as three different names.

---

13.1.2. 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 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 manageable.

• 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 blind . In other words, let someone who's unfamiliar with how your animation's 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 Section 13.2, 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 Web site, upload your files (including your .swf file and any external files your animation depends on) to a Web server and 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 differencebut it often does.) Chapter 14 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 must eventually fire it up in Flash Player. Here's some more advice on when to choose each:

• Testing on 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 dont 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 handyno 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 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 doesnt work on the Stageeven though it may work perfectly well when you test it in Flash Player.

• Testing in the built-in Flash Player (Control Test Movie and Control Test Scene) is the more accurate option. When you test an animation by selecting Control Test Movie or Control Test Scene, Flash generates a .swf file. For example, if youre 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 that .swf file into Flash Player (test window) that's part and parcel of the Flash development environment. This testing option shows you exactly what your audience will see, not counting computer hardware and connection differences (Section 10.1).