O’Reilly: Inside RIA

In part one of this article, we demonstrated how to create some basic and simple unit tests using Fluint. Those work well for very basic situations, but even an average Flex application will use events and have asynchronous aspects. This article will build on the last and demonstrate how to test systems with these concepts in mind. You will learn to write unit tests that wait for events to occur before continuing and whose success or failure may depend on something that happens sometime in the future.

Software developers are a lazy group of people. It’s true. It’s what makes us good at our job. We have an intrinsic need to find an easier, or at least faster, way to do things. Of course, we also tend to be a stubborn group of people. It’s rare that someone can change our mind, we usually need to experience something ourselves to understand why it matters.

That’s what this series of articles is about. I will tell you the reasons that my team writes tests. I will tell you what we get out of it. However, I will also show you that the barrier to entry is small and that writing tests is something you can try without a big commitment.

The following has been excerpted from Adobe Flex 3: Training from the Source by Jeff Tapper, Michael Labriola and Matthew Boles with James Talbot. Copyright © 2008. Used with permission of Pearson Education, Inc. and Adobe Press. In this lesson, you will learn about both memory and performance profiling, two techniques facilitated by the new Profiler feature in Flex Builder 3 Pro. (Note: The new profiling feature is only available to users of Flex Builder 3 Pro. An evaluation version of Flex Builder 3 Pro is availabl from www.adobe.com/go/flex/. Flex Builder Standard users will not be able to access the profilerscreens.) To understand the need for this tool, you need to learn some details about how Flash Player executes code in Flex and how it allocates (gives) and frees (takes back) memory.