Sunday, August 23, 2009

Why I am excited about Azure Platform's .Net Service Bus?

Basically, the following statement:

"...Full-duplex, connection-oriented peer-to-peer sessions with network-boundary traversal create direct end-to-end connectivity through NAT"

That's awesome... because any developer that has ever tried to create a real-time, Peer-to-Peer application, he/she knows what hell it is to penetrate firewalls specially Symmetric NATs. Click here to learn about NATs

The Service Bus enables secure, loosely-coupled connectivity between services and applications to navigate firewalls or network boundaries, using a variety of communication patterns. The Access Control service provides an enterprise-class mechanism for federated authorization across organizations and protocols.

In the same way that Microsoft® .NET Framework provides higher-level libraries to make developers more productive, .NET Services help developers focus on their application logic rather than deploying and managing their own cloud-based infrastructure."

Azure's .Net Service Bus enables developers to build applications for the cloud and offers a scalable hosted infrastructure for deploying and managing these applications and their data stores combined with a workflow engine and a security infrastructure. The Azure Service platform is the new OS for internet scaled applications.

Lower Barriers to Building Composite Applications

Using the Service Bus, an application or service can expose and access endpoints that would otherwise be hard or impossible to reach. For example, the endpoints may be located behind network address translation (NAT) boundaries or bound to frequently changing, dynamically assigned IP addresses.
  • Exposes Service Endpoints Easily

    -- Users can access a global hierarchical namespace that is DNS- and transport- independent

    -- Services can be located through a stable, Internet-accessible URL, irrespective of location.

  • Offers Multiple Connection Options

    -- One-way messaging between sender and listener supports unicast and multicast datagram distribution

    -- Full-duplex connection-oriented sessions between sender and listener support bi-directional communication

    --  Full-duplex, connection-oriented peer-to-peer sessions with network-boundary traversal create direct end-to-end connectivity through NAT

  • Supports Publish and Subscribe for Multicasting

    The simple publish/subscribe model lets multiple publishers and multiple subscribers simultaneously use the service’s topic management and event distribution system.

Learn more:

WCF Hosting

Windows Communication Foundation (WCF) Services can be hosted with Internet Information Services (IIS); with the new Windows Activation Service (WAS) installed with IIS 7.0; or with any managed application process including console, Windows Forms, Windows Presentation Foundation (WPF), or managed Windows service applications.

Selecting the right hosting environment for your services is a choice driven largely by deployment requirements related to transport protocol and operating platform.

A summary of hosting options and supported features:

Feature Self-Hosting IIS Hosting WAS Hosting
Executable Process/ App Domain Yes Yes Yes
Configuration App.config Web.config Web.config
Activation Manual at startup Message-based Message-based
Idle-Time Management No Yes Yes
Health Monitoring No Yes Yes
Process Recycling No Yes Yes
Management Tools No Yes Yes

A summary of hosting options based on operating platform and communication protocol:

Operating Platform Protocol Hosting Options
Windows XP/SP2 HTTP IIS 5.1 or self-host
Named Pipes, TCP, MSMQ Self-host
Windows Vista HTTP, Named Pipes, TCP, MSMQ WAS or self-host
Windows Server 2003 HTTP IIS 6.0
Named Pipes, TCP, MSMQ Self-host
Windows Longhorn Server HTTP, Named Pipes, TCP, MSMQ IIS 7.0/WAS or self-host

Memories of our band: Tatva - The Element

I was going through some Audio CDs while cleaning my office and stumbled upon a CD from our Band - Tatva - The Element.

Tatva's music can be described as: "rustic Indian folk transposed into western, popular rock rythms..."

Check out our music and please let us know what you think about it.

Facebook and Flex: Rock On!!!

I've been incredibly motivated and enthusiastic about Flex since I first started working with it back in early 2007. I have created Flex based interfaces for desktop apps (C++ container) and medium and large web-based apps. I have always loved Flex for the ease of use and the power it gives to developers.

Flex is, hands down, the best RIA technology available today. Flex is fast becoming the primary technology for building Rich Internet Applications.

Facebook, on the other hand, is the best, most powerful and the fastest growing social networking platform. The real power of facebook is not because of "social" (there's LinkedIn and other websites for that!)... the power is in the "platform". If you don't agree with me, just look at what Apple did with its Application platform! It's making much more money after it opened its platform to developers. Facebook would be nothing but a better and clearner looking LinkedIn, if it wasn't for the applicaiton platform.

Most of my friends use Facebook for the applications. They probably spend 10-20% of their time managing their profile and friends (social graph) and the rest on apps like iLike, Zombies, Mafia War etc etc. Good or bad, these apps have an audience - A global, over 200 million large audience. So, if you have an apps, that costs, say $1, and appeals to only 1% of the audience - you have the potential to make $2 million!!!! THAT'S THE REAL POWER!!!!!

Facebook's Ad Platform is not as good as Google's AdSense, but that is another area that can generate a lot of money for not just Facebook, but the application developers. Under Facebook's COO, Sheryl Sandberg's guidance that will likely change. Check out this Forbes article.

So, if you combine the best RIA technology (FLEX) with the best Social, Application platform (FACEBOOK), you can make a killing!!! You can deliver rich, social experiences on the web.

This is what Adobe Developer Connection website has to say:

The Adobe Flash Platform and Facebook Platform provide the ideal solution for building rich, social experiences on the web. Flash is available on more than 98% of Internet-connected PCs, so people can immediately access the applications, content, and video that enable social interactions. The Facebook Platform is used by millions of people everyday to connect and share with the people in their lives. Together, both platforms allow you to:

  • Share: Create rich interactions for users to share with friends.
  • Have fun: Make games social; let users compete against their friends.
  • Connect: Let users connect to your RIAs with Facebook Connect.
  • Solve problems: Build RIAs that harness the power of community.
  • Reach people: Reach millions of Facebook users through social distribution.

The new ActionScript 3.0 Client Library for Facebook Platform API, fully supported by Facebook and Adobe, makes it easy to build applications that combine the strengths of the Flash Platform and Facebook Platform.

I am back...

I am back to my personal blog after a long break. While I was away, I got married, switched jobs and started some new projects. I'm excited to be back to my personal blog.

Monday, March 02, 2009

Know your Customer :)

A disappointed salesman of Coca Cola returns from his Middle East assignment. A friend asked, "Why weren't you successful with the Arabs?" 

The salesman explained, "When I got posted in the Middle East, I was very confident that I would make a good sales pitch as Cola is virtually unknown there. But, I had a problem I didn't know to speak Arabic. So, I planned to convey the message through three posters... 

First poster 
- A man lying in the hot desert sand...totally exhausted and fainting.

Second poster - man is drinking our Cola.

Third poster- Our man is now totally refreshed.

Then these posters were pasted all over the place

"That should have worked," said the friend.




The salesman replied "I also didn't realize that Arabs read from right to left"

Develop Web services clients with Macromedia Flex

Flex the power of Web services by learning how to easily leverage them within a Rich Internet Application (RIA) using Macromedia Flex for a more complex, engaging, and interactive client-side experience. RIAs are an evolution of the traditional Web page based model for Web applications. A big part of the attraction in using Flex for RIA development is the speed and ease with which you can leverage Web services in your applications. The authors walk you through several examples and simplify how sometimes confusing WSDL constructs map to Flex declarations.

Selecting the Right Flex Application Framework

So you’ve decided to use Flex for your web application development. It’s easy to follow the online tutorials and prototype an application, but deciding on an application framework for your major production Flex application is more difficult. The Flex community is divided between Adobe’s Cairngorm and Cliff Hall’s PureMVC, with strong arguments from both sides. However, your answer may just lie in the “it depends” space.

This post aims to help you make that decision. It includes analysis of CairngormPureMVC, and the new kid on the block, asfusion’s Mate.


Cairngorm (pronounced \kern-gorm\) is a lightweight micro-architecture for Rich Internet Applications for Flex or AIR applications. It is not only a framework, but also an approach to organizing and packaging code, components, and a method to achieve separation of concerns (i.e. model-view-controller).

Compared to other frameworks, Cairngorm requires the most components, but it is the most straightforward.

Cairngorm Framework
Figure 1 Cairngorm Framework

  • Advocated by Adobe Consulting and is part of the Adobe Engagement Platform.
  • Broadest adoption for a Flex MVC framework, making it the de facto standard for Flex developers
  • Well-documented with great tutorials.
  • Designed expressly for Flex and thus, takes advantage of Flex features.
  • Simple, straightforward MVC framework
  • Tightly couples the MVC layers.
  • Components can either be too large or too many, resulting in the application becoming too unwieldy from the development and maintenance perspective.

Tips and Tricks

  • Use packaging, sub-classing, or helper classes to prevent unwieldy model locators and controllers.
  • Use Adobe Consulting’s Observe Utility to prevent tight coupling between the view and the model locator.
  • Minimize direct references to the model locator from the view, by passing data references between parent and child components.

Recommended When:

  • The team and/or the organization are new to application development, ActionScript and/or Flex. It is good for new Flex developers to learn Cairngorm before other frameworks first. Management will also be more comfortable with an Adobe-backed framework.
  • You need a quick prototype.


PureMVC is also a lightweight framework for creating applications based on the classic MVC concept. PureMVC is not specific to Adobe Flex and is being ported to other languages. Many Flex developers consider the framework to be the best Flex framework out there, but accept that it does not take advantage of Flex features.

PureMVC Framework
Figure 2 PureMVC Framework

  • Provides flexibility to easily support complex workflows, e.g. command chaining.
  • Promotes code reuse.
  • Cleaner architecture and implementation, i.e. layers are more loosely coupled.
  • Well-documented, but not many tutorials.
  • Not designed expressly for Flex, and thus, has been criticized for not taking advantage of basic Flex features, such as data binding.

Tips and Tricks

  • Since the framework is language-agnostic, it cannot rely on data binding innately. But this doesn’t mean binding can’t be implemented in PureMVC Flex applications. Use the mediator to bind the data from the proxy to the view component.
  • Use a proxy for a service locator.
  • Reuse mediators for multiple view components.

Recommended When:

  • The application has complex logic and/or repeated logic.
  • If you need an MVC framework that cuts across the different languages of your application, e.g. Java and Flex. However, some of the PureMVC language ports are still in alpha.


Mate (pronounced \mah-teh\) is the newest Flex application framework. It is also designed expressly for Flex. Its main differentiator from Cairngorm is that it uses dependency injection to hook the event handlers to controller entities and view properties to the data model (via injectors). Thus, it requires the least number of components of all of the frameworks.

Mate Framework
Figure 3 Mate Framework

  • Provides flexibility to easily support complex workflows, e.g. method invoker chaining.
  • View can be simple and uncluttered, i.e. injectors can enable the view to not even reference Mate components, except for within the application MXML.
  • Promotes code reuse, e.g. invoked or referenced custom entities do not need to extend any base classes or interfaces.
  • Well-documented, including tutorials, examples and best practices.
  • Nullifies the power of AS3 compile-time type checking with the EventMap MXML.

Tips and Tricks

  • Flex events thrown must have its bubbling setting set to true.
  • Use multiple event maps to break down event type concerns.
  • Take special care in structuring and designing the controller entities.

Recommended When:

  • You need a really quick prototype.
  • The application has complex logic and/or repeated logic.
  • Your team has designers or component developers, not responsible for integrating the UI with the business services.
  • You have an existing Flex application that needs a framework refresh. You can quickly reuse the AS classes that have already been created and string them up using the event maps.


  • Slide is Peter Joel’s work in progress. It has been released, but there is still a lot of work being done on it, and thus, little documentation is available. Its concept of view states by URIs and acknowledgement of data and navigation to drive view states is interesting though.
  • ARP (Ariaware RIA Platform) is Aral Balkan’s effort, borne from Flash 5. Its latest version finally supports Flex. It’s very similar to the Cairngorm framework with the inclusion of base classes for commands, controllers and forms. It also makes a distinction between system and view events. However, it doesn’t present a strong compelling differentiation from the Cairngorm framework, but seems to be a viable solution as well.
  • Foundry is another application framework, built for ActionScript and based on the MVC pattern, by Servebox. It is also very similar to Cairngorm, but heavily advocates the use of view helpers. Like ARP, the framework doesn’t provide a strong differentiation from Cairngorm, but seems to also be a simple, viable framework to use.
  • Guasax is a Flex application framework, but is not based on the MVC pattern. Like Struts, it uses configuration files to set up actions invoking business objects and setting up interceptors for those actions. At first blush, the framework seemed too complex, and examples online are not commented in English.
  • Flest is a Flex application framework that uses model, view, and controller components, but does not claim to be an MVC framework. The suggested use of the provided components is to tightly couple them within the application (e.g. commands are closures to the controller). Thus, it didn’t appear to be an ideal framework in easing maintenance of the application.
  • MVCS is an architectural blueprint for Flex applications, based on the MVC pattern. Joe Berkovitz’s article on Adobe Developer Connection is definitely worth the read. The concepts in the article are helpful when designing your application. But MVCS is not packaged as a reusable framework.

Sunday, March 01, 2009

Top 10 Adobe Flex Misconceptions

At QCon, Adobe's James Ward shared with the top Adobe Flex misconceptions that he encounters in his travels evangelizing the Flex application framework.
  1. Users Need to Install Something New to Run Flex Applications. 

    Ward, exclusive to, discusses the Flash adoption rates and Flex programming model:
    Flash Player 9 is required for Flex 2 & Flex 3. The Flash Player 9 runtime is currently installed on 94% of the world's computers: 

    Flex 2 and Flex 3 applications execute in the Flash Player 9. Flex applications are built on top of the native Flash Player APIs like vector graphics, bitmap manipulation, and networking (which are based on the browser networking stack). The Flex framework adds reusable components like date pickers, data grids, charts, etc. Compiling a Flex application results in a SWF file which is the binary byte code format for the Flash Player. Contained in the SWF file is the byte code for the Flex framework code and a project's custom code. The Flex compiler optimizes the byte code so that only classes which are used go into the SWF file. 

    For desktop applications, Adobe is aiming to make their new desktop runtime, dubbed Adobe AIR, as ubiquitous as the web runtime. The 1.0 release of Adobe AIR will be available in the beginning of 2008. Currently, AIR is in beta release from Many companies are already building production applications on AIR. One example, can be seen with eBay's application eBay Desktop.
  2. Flash Player is 100% Proprietary. 

    Ward continued on this item for
    The core of Flash Player is the Tamarin Virtual Machine, which is an open source project under Mozilla. While the SWF file format is not fully open, it is documented by the community on There are numerous open source products that read and write SWF files. The Flash Player's product direction has traditionally been heavily influenced by the community and their needs. The core language for Flash Player is an implementation of ECMAScript 262, which is the specification for JavaScript. Flex also uses CSS for styling of components / applications. Adobe AIR uses web standards as the basis for desktop applications as well as Open Source technologies like Tamarin, Webkit, and SQLite.
  3. Flash is for Designers, Video, and Annoyances. 

    In Ward’s July, 2007 blog, “How I Overcame My Fear of Flash,” he discussed this point:
    Indisputably, the power of Flash has been abused. Pop-ups, pop-overs, skip intros and annoying ads run rampant across our screens. I've heard it said that one should never judge a religion by its abuse. The same adage applies to technology. Flash shouldn't be avoided just because people use it for annoying things. After all, e-mail isn't avoided just because spammers happen to abuse it.
    Ward elaborated on the topic for
    Traditionally Flash content was built with the timeline based tool for designers. Flex is the developer toolset for building Flash based content / applications. Designers and developers can work together by sharing assets between the two tools. Flex adds a comprehensive component base:
  4. Flex is Not for Enterprise / Business Applications. 

    Over the last few weeks, Ward published a seven part blog series on a number of new Oracle applications implemented in Adobe Flex. The applications, which were announced at the recent Oracle OpenWorld, ranged from sales tools, to database management, and business intelligence.

    In addition to Oracle’s usage of Flex, published a piece recapping a number of groups using Flex for enterprise applications. Ward also points out to, that there are numerous examples of enterprise applications being developed with Adobe Flex, including work at: Workday, SAP, Salesforce, and Business Objects. 

  5. Flex is Expensive. 

    Ward detailed a number of things Adobe has done to address the cost concerns:
    Flex is a free, and soon to be open sourced, developer toolkit for building Rich Internet Applications for the web and the desktop. This free SDK includes everything a developer needs to build RIAs that work the same on any browser or operating system. Part of the free Flex SDK is an extensive set of components which are extensible, skinable, and accessible. You can see many of these components in the Flex Component Explorer: 

    Flex Builder is an optional plugin for Eclipse which makes developing applications with the free Flex SDK more efficient. It includes features like integrated debugging, design view, and code completion. 

    The Flex Builder pricing has changed in quite a few ways recently. Flex Builder is now free for Students and Faculty. The price for the vanilla Flex Builder, without the charting components, has been reduced to $249 to better balance the tiered pricing for Flex Builder.

    There are a number of options for building backend infrastructure for Flex Applications. To take advantage of the high performance AMF data transfer protocol, there are official Adobe products like LiveCycle Data Services, as well as numerous open source projects like Granite Data Services. Using AMF removes the unnecessary steps of converting data to text (SOAP, RESTful, etc), transferring it, and then converting it back to data. AMF also allows type information to be preserved across the wire.
    To see a comparison of AMF to other text based serialization technologies, see James Ward's Census RIA Benchmark application:

  6. Flex Applications Require a Special Server. 

    Once again, Ward speaking with
    Flex applications can run on top of any web server, application server, and database server. Flex applications are much more like client-server applications. Since the logic is running on the client inside the Flash Player, you need some way of communicating with the server. There are many different options for how you connect Flex to your infrastructure. Without any special libraries, you can expose your back-end data and services as RESTful, XML, or SOAP and easily consume that data in your Flex application. If you choose to use the AMF binary serialization protocol, you may need to add some additional libraries into your web application. AMF is just another serialization technology, like XML or JSON, so it can be one of the various methods you use to communicate to your back-end SOA.
  7. Flex is Hard to Learn. 

    Leftie Friele, from the community, posted a comment on the piece “Who is Using Flex?”, detailing his company’s experience in learning Flex:
    Our startup company, Ezmo, have used Flex since the start and we're extremely happy with the framework. 

    Without any prior knowledge of Flex/Flash, we built our application in less than two weeks. The integration between Java and Flex is super simple, and getting started with Flex is just a walk in the park. 

    The tool support is very good too with Flex Builder. You get the familiar surroundings of Eclipse and you are off and running without many problems. The one thing that is missing is better tools for continuous integration and better plugins into Maven for building Flex applications.
    For those new to Flex, Ward has a Screencast showing a Flex application being built to help get you started. There are also numerous other articles about using Flex and Java in the Adobe Developer Connection. 

  8. With Flex, I Will Need to Rebuild My Entire Application. 

    In January, Bruce Eckel published an article titled, “Hybridizing Java.” He argues that the Java community should continue using the good parts of Java, but should use other technologies where Java is weak. His primary focus in the article is using Adobe Flex for user interfaces, instead of the traditional Java options (Swing, JSF, etc…). 

    Ward elaborates on this concept:
    Since Flex applications are just the UI piece of an application the back-end usually stays the same. If your back-end was built following the SOA pattern then it is usually very easy to expose those services out to a new Flex UI. This preserves your existing business logic whether it is in EJBs, Spring services, POJOs, etc.
  9. Flex Breaks Normal Browser Functionality, Like the Back Button. 

    Ward’s blog discusses the back button:
    In Flex, back button support is built in and easily customizable so this was never an issue. Flex also provides an easy way to do hashmark urls (or named anchors), so the url changes as application state changes. Another Web 1.0 integration problem solved.
    Ward adds more details for
    Flex 3 provides a simple way for applications to store state parameters in a named anchor and correctly restore state based on those parameters when the URL is requested. More information about this feature can be found in the Flex 3 Feature Introductions Deep Linking documentation. 

    Accessibility has always been very important for Flex applications. Since the Flash Player works with Jaws and other accessibility technologies, the capability for adding accessibility to Flash based applications is there. The Flex framework builds accessibility into the core framework. There are many different pieces of accessibility depending on what impairments and disabilities your application needs to support. You can find out more about the accessibility features of Flex in the Developer's Guide.
  10. I Can Do Everything Flex Does With Ajax. 

    Ward explains:
    RIA with Flex and Ajax is not either/or. Sites like Google Finance show how you can use Flex and Ajax together. Ajax is very good for content-centric applications, while Flex is very good for interactive, media, and data-centric applications. If your application is somewhere in between the two sides of that spectrum, then you can use the Flex Ajax Bridge to combine the two technologies. In Flex 3, the Flex Ajax Bridge is integrated directly into the SDK. If you are using Flex 2, you will need to download the Flex Ajax Bridge separately.
    Also, from the community, Michael Marth commented on why his group chose Flex:
    We use Flex 2 for our soon-to-launch online dating site 

    The reason: Flex enabled us to create a user experience far beyond anything that we could have done with a comparable effort in Javascript/Ajax.

Saturday, February 28, 2009

Screencast: Watch a Flex app built in 11 minutes

James Ward recorded a screencast of him building a simple Flex app with Flex Builder.

Check it out:

FlexUnit - Test Driven Development (TDD) for Flex

Unit testing and Test Driven Development (TDD) for Flex and ActionScript 3.0

Unit testing isn't a particularly common practice among Flash developers. Perhaps that's because so many of us are self-taught and not aware of what goes on in other languages, or perhaps it's because, until recently, many Flash-based projects were relatively small-scale.

In this article, I am going to deal with the how and what, but not necessarily the why for Test Driven Development for ActionScript 3.0 and Flex 2. If you want to know 'why', a simple Google search will return a plethora of resources.

I'll do my best to collate and share what I have discovered over this period and show you how to unit-test using FlexUnit, hopefully saving you from some of the frustration and head-scratching I experienced.


FlexUnit from Adobe Labs

flexunit .zip (ZIP, 1.8 MB)

Prerequisite knowledge

Object-oriented programming (OOP), and some ActionScript 2.0 (enough to understand ActionScript 3.0.)


Test Driven Development is one of the rules of eXtreme Programming (XP).

Originally, XP programmers wrote tests for any part of their code that could break. However, this soon evolved in to the practice of writing the tests before writing the actual code. This may sound strange, but there is reason behind this madness; by knowing what can go wrong, you have a better idea of what your code needs to be able to handle.

TDD has evolved in to a process by which code is generated, as opposed to a testing process. It does still effectively perform tests, but that is more of a by-product.

The first thing you need is a Unit Testing framework. You can write your own, but that is not necessary. Most people use one of the existing frameworks such as FlexUnit or ASUnit.

In TDD, functionality is added in very small chunks: You come up with a test, you write the test, you write the code to satisfy the test, possibly refactor it to make it more efficient, and then start with the next test. Each test may only take a minute or so to write; it may take 10; one test should not take hours though.

This quote, from Dave Astels gave me my first clear definition of TDD:

"It's about figuring out what you are trying to do before you run off half-cocked to try to do it. You write a specification that nails down a small aspect of behaviour in a concise, unambiguous, and executable form. It's that simple. Does that mean you write tests? No. It means you write specifications of what your code will have to do. It means you specify the behaviour of your code ahead of time. But not far ahead of time. In fact, just before you write the code is best because that's when you have as much information at hand as you will up to that point. Like well done TDD, you work in tiny increments... specifying one small aspect of behaviour at a time, then implementing it." – Dave Astels

There is in fact a kind of "testing dance" you perform, and it's known as the Test-Code-Simplify cycle:

The Test-Code-Simplify cycle (Quoted verbatim from "Extreme Programming Applied", p159):

  1. Write a single test
  2. Compile it. It shouldn't compile, because you haven't written the implementation code it calls
  3. Implement just enough code to get the test to compile
  4. Run the test and see it fail
  5. Implement just enough code to get the test to pass
  6. Run the test and see it pass
  7. Refactor for clarity and "once and only once"
  8. Repeat


I'm going to use FlexUnit for this tutorial. The "Flex" part may be a little misleading. You doneed Flex in order to use it, but the framework can be used to test pure ActionScript 3.0 files as well.

Before looking at how to use FlexUnit, let's get familiar with some terminology. Bear with me—it's a bit of a chicken and egg situation, and will make more sense as you construct tests later on.


An assertion is a statement of expected outcome. In other words, it is the expected result of your test. You may assert that the sky should be blue, or that you want x to be equal to y. In TDD if your assertion turns out to be something other than what you expected, you write code to correct that in your class.

test fixture

There may be some setup that is constant across all of your tests. For example, each test may depend on the creation of a certain object, property or process. A test fixture is useful if you have two or more tests for a common set of objects, as it avoids duplicating the code necessary to initialize and clean up the common objects. Methods called setUp() and tearDown() are provided for this common code, and any properties used can be declared at the top of the class.

test case

A test case is the smallest unit of testing. It checks for a specific response to a particular set of inputs. Your test class must extend the TestCase class and have a constructor that calls the super class's constructor. In some frameworks, all test methods should begin with the word "test." So if you are testing that the beer is cold, your method will be called something liketestBeerIsCold().

test suite

As more and more unit tests accumulate for a given project, you will want a way to group them. Running them one at a time would be cumbersome. A TestSuite can contain other TestSuites,or individual tests, and is a way of declaring which test must be run in the same session, regardless of whether or not they are in the same file. This way of aggregating tests is very handy as you'll soon see.

test runner

A test runner is a component that often has a graphical interface and displays the outcome of our tests. In FlexUnit you tell your TestRunner which TestSuite you want to use, and then call its startTest() method.

test harness

The class that extends TestCase may contain a test suite, will contain test cases and may possibly contain test fixtures. From what I can gather this class is referred to as a test harness, although usage of this term seems to vary in the documents I've looked at. Some documentation considers that the harness is the process that instantiates the runner and passes in the suites that you want to run, while Wikipedia defines a test harness as the an Automated Test Framework (ATF).

Congratulations if you managed to get through all that. It wasn't exactly exciting reading, but they are useful terms to refer back to as you look at the examples below.

Let's get on with installing FlexUnit and creating our tests...


Installing FlexUnit is pretty straight forward. You get the Flex Unit source files, set up a Flex project, and in the process, you specify that the project should use the flexunit.swc file:

  1. Get the flexunit .zip archive (from the Requirements area) and extract it to your hard drive. I created a new folder on my C drive called FlexDev and extracted it there, so the path on my machine is C:\FlexDev. Once extracted, FlexDev will contain a folder called flexunit, which in turn contains further sub folders (bin, docs and src folders).
  2. Create the Flex Project. Open up FlexBuilder 2 and create a new Flex project using: File > New > Flex Project.
  3. Choose a Basic Service (in other words, not Data Services) and press Next.
  4. Give your project a name of 'TDD Example', deselect the Use default location option, and browse to the same location as before (on my machine this is the C:\FlexDev folder). This is the location where you are going to set up your project. Click Next. (If you pressed Finish by mistake, skip to the end of this list).
  5. Select the Library Path tab, click the Add SWC… button and browse to the SWC file, which is in the bin folder of flexunit (using my set-up, the path is C:\FlexDev\flexunit\bin\flexunit.swc).
  6. Press Finish button and you're done.

Note: If you need to add the SWC file to an existing project, right-click your project folder, select properties from the pop-up list and continue from step 5 above.


You're almost there. First I am going to briefly describe the three files that you are about to create:

  • The first file is the .mxml, (which is set as the default application for our Flex project). This file contains an instance of the TestRunner component (the visual component that displays the test results). The file specifies to the component which test suites you want to run, and then starts the test. I simply called this "main.mxml."
  • I'll refer to the second file as the test class. It is the one that contains the "test runner." Some developers refer to this as the test harness and some would simply call it a test runner. In this file, decide what you need to assert, and then write your test cases in it. I've named this as the example in this tutorial relates to money.
  • Finally there is the actual class, Build this file up bit by bit as you create more and more tests.

Creating main.mxml:

Here is the MXML that belongs in the main.mxml file. Open up the file and copy and paste this in:

<?xml version="1.0" encoding="utf-8"?>


private function onCreationComplete():void
testRunner.test = AccountTest.suite();
<flexunit:TestRunnerBase id="testRunner" width="100%" height="100%" />

There are a few things to notice:

  1. We've defined a new xml namespace in the Application tag
  2. We have a creationComplete even calling our onCreationComplete method
  3. we created an instance of TestRunnerBase

We defined a new xml namespace in the Application tag:


If you have created your own components in Flex before, this will be familiar to you. If not then I will briefly explain.

This creates a namespace called "flexunit," which refers to components located in the flexunit.flexui package. We have access to this package of course, because you associated the flexunit.swc file with the project library earlier.

To instantiate an instance of the component in MXML, you can use code similar to the following:

<flexunit:TestRunnerBase id="testRunner" />

If you had declared your namespace as "bananas", you would instantiate your component using code similar to:


<bananas:TestRunnerBase id="testRunner" />

But you've used common sense and gone for a more descriptive name.

The TestRunnerBase component is TestRunner (see the "Understanding Terminology" section, above, for a refresher). I assigned it an id of testRunner.

In the Application tag you also have the creationComplete event handler, which callsonCreationComplete(). This method sets the test suite(s) you are going to use, and then calls the startTest() method of the TestRunner to put everything in to action.

Finally, underneath the script block you instantiate our TestRunner as previously described, with a width and height of 100%.

Okay, that's it. You'll be glad to hear that you don't really need to touch this file again in this tutorial.


Create a new ActionScript file in the main project folder (at the same level as main.xml) called, and paste the following code into it:

    import flexunit.framework.TestCase;
    import flexunit.framework.TestSuite;
    public class AccountTest extends TestCase
        public function AccountTest(methodName : String){
        public static function suite():TestSuite{
            var accountTS:TestSuite = new TestSuite();
                //tests are added to the suite here
            return accountTS;
    } }

There are a few things to notice:

  1. The class extends TestCase.
  2. There is one static function called suite (which returns a TestSuite).
  3. The constructor calls its super class, passing it some method name.


Finally, you must create the Account class. Create a new ActionScript file in the main project folder (at the same level as main.xml and called and paste the following code into it:

    public class Account
        public function Account(){

Not much to say about this. It is the bare bones of the actual class.


I'm going to plagiarize (with permission) the example used by Simon Whacker to demonstrate as2lib's unit testing, because it was particularly clear and easy to understand.

We are going to create an application for a bank, and our first requirement is to allow the creation of a new account.

The first question to ask yourself is: When creating a new account, what should happen? Well, not much. Despite my best wishes, whenever I open a new account, it always starts off empty. How do I know that for sure? Well. I know because I can check my balance. So, when I open a new account and check my balance I should have £0.00 in there. Okay, we have our first test.

Remember, in this tutorial, we write our test before we write the code in our class, and this is how it works:

In, underneath our static "suite" method, paste in this code:

public function testNew():void{
    var account:Account = new Account();
    assertEquals("Expecting zero account balance", 0, account.getBalance());

Note: In some frameworks all tests must start with the prefix "test." With FlexUnit, this rule doesn't seem to be enforced, but for consistency I recommend doing so anyway. One reason to require any test method to start with "test" is that you can then shortcut the suite creation process. Simply introspect a class and any function that starts with "test" is considered a test.

In this case, you are testing the creation of a new account and so the method is called testNew.

As you can see, you create a new instance of the Account class, and then use an assertion method called assertEquals.

There are various types of assertion, but assertEquals basically checks that the two values passed in are ... [drum roll] ... equal. The eagle eyed among you may have noticed I am actually passing in three values:

  1. The first value is optional. It is a String and it should clarify the outcome you are looking to satisfy. In this case: "Expecting zero account balance."
  2. The next value is 0.
  3. The last value is a call to an, as yet non-existent, method of our Account class calledgetBalance(). I will write this in a moment.

Overall, this assert specifies that you want the value returned from getBalance() to equal zero.

Note: TestCase extends Assert, so there is no need to import the Assert class in order to use these assertion methods.

All you have to do now is add your test to the test suite.

Amend the static suite function in the AccountTest class to look like this:

public static function suite():TestSuite{
    var accountTS:TestSuite = new TestSuite();
    accountTS.addTest(new AccountTest("testNew"));
    return accountTS;

You can see from the above code that I use the addTest method to add the test to the TestSuite. The object passed in is actually an instance of AccountTest (in other words, the class you are in). The name of the test to run, gets passed in as a String...

If you remember, the constructor for AccountTest looks like the following code:

public function AccountTest(methodName : String){

It accepts the methodName of the test, and passes it on to its super class.

Note: This is the way I first learned to test, but you don't have to do it like this. The framework will automatically find all "test" methods in a TestCase if you pass the class reference to the constructor of a TestSuite.

Test It!

Okay, the setup is done. It's time to test.

If you think back to the Test-Code-Simplify cycle of eXtreme Programming that we looked at earlier. The first couple of stages were:

  • Write a single test.
  • Compile it. It shouldn't compile, because you haven't written the implementation code it calls

You've written a test, so try and compile the project.

The Errors window

Figure 1. The Errors window

The Flex Builder Problems pane should also be reporting the following error:

"Call to a possibly undefined method getBalance through a reference with static type Account."

Great! That's what we want. You haven't written getBalance() yet And so you should quite rightly have a compiler error.

Note: If you actually choose to ignore the error and run the application anyway, you will see the TestRunner, and the test will actually pass! I didn't expect this to happen so be aware of it. It is fine to ignore Flex Builder warnings (in fact, the kind of tests you'll do will probably cause a few warnings) but don't ignore compile-time errors.

From further research, I found out that the test passes based on the last time you saved. So if you saved an empty test method, it would work; or, if you saved the empty testcase it would run and report no failures. When there are compiler errors, a new SWF file doesn't replace the old SWF, so you are in fact running the old SWF file.

Now take a look at the next two steps in the Test-Code-Simplify cycle:

  • Implement just enough code to get the test to compile.
  • Run the test and see it fail.

Amend the Account class to look like this (additions are highlighted in yellow):

    public class Account
               private var _balance:Number; 
               public function Account(){
       public function getBalance():Number{
            return _balance;

You now added your getBalance() method, which returns _balance, and you have also declared this variable called _balance (intended to hold our account balance amount of course), but _balance hasn't been initialized with a value yet. Compile, and you should see something like the following:

The TestRunner GUI

Figure 2. The TestRunner GUI

This error is a good thing! Here we can see the test that failed (testNew) and why it failed. The big red bar would be green if the test had passed.

Now you know your TestRunner is working properly. You know the test should have failed, you know your test did fail, and you know why it failed.

The TestRunner tells us that it expected a value of zero but received a value of NaN (Not aNumber) which is what ActionScript 3.0 returns (variables typed as Number and not assigned a value are returned as NaN in ActionScript 3.0).

Continuing on, the next two steps in the Test-Code-Simplify cycle are:

  • Implement just enough code to get the test to pass
  • Run the test and see it pass

All you need to do now is give _balance an initial value of zero. Change your Account class's constructor to look like the following:

public function Account(){
    private var _balance:Number = 0;

Now run the test:

The test succeeds

Figure 3. The test succeeds in the All Tests tab

Bingo. The bar is green. Here we are viewing the "All Tests" tab in the left pane, which shows that the testNew test has passed. You know it passed for the right reasons too, because you saw it fail when conditions were wrong.

The final two points in the Test-Code-Simplify cycle are:

  • Refactor for clarity and "once and only once"
  • Repeat

There's little need to refactor here, and so on with the next test.


You've completed your first test—the hard part is over with. Take a break if you're exhausted because in order to see the real value of TDD we are going to implement a couple of extra tests. Most of the following code will be copy and paste with little need for additional explanation, so it shouldn't take long to get to the end now


In many ways this next part of the tutorial is the most important. I hope to demonstrate how TDD can help you spot mistakes and prevent you from making changes which could break existing code and leave you unaware. Catching these problems when they occur, can save hours of debugging and headache further down the line.

Let's say your bank customers can open an account and now they need a way to credit their accounts. I'm sure you can think of plenty of things you need to test for here. Just as an example:

  • crediting an account with a null amount (avoid this!)
  • crediting an account with a real value (must work!)
  • crediting an account with a negative amount (that's a debit not a credit)
  • an account credit which includes fractions of a penny (how to handle?)

We're not going to implement all of these, but we'll use a couple of them to highlight some points.

Credit with null value

This seems pretty straight forward so first let's write the test:

public function testCreditWithNullValue():void{
     var account:Account = new Account();;
     assertEquals("Expecting zero account balance", 0, account.getBalance());

Again, you have called a method that doesn't exist yet credit(), but in doing so you have effectively specified that it is required, and must be capable of accepting a value. This shows how TDD helps you write your specifications.

Now add your test to our test suite:

accountTS.addTest(new AccountTest("testCreditWithNullValue")); 

Check that your application doesn't compile; sure enough, Flex Builder gives you a compile error because you haven't written the credit() method yet.

Next, write just enough code in the Account class to let it compile.

public function credit(amount:Number):void{
    _balance += amount;

Run the test and see it fail:

Only, this one doesn't fail.

Flex Builder warns is that AccountTest ('null' is being used where 'Number' is expected), but there is no error. In fact ActionScript 3.0 appears to handle the attempt at passing in a null and returns a balance of zero.

In ActionScript 2.0, adding null to zero would equal NaN (Not a Number), so let's quickly check that our assumption about this is correct by making the test fail on purpose.

Change the code as follows: + 10); 

When we run the test it does indeed fail, because it is expecting zero, but receives 10. It looks like the code is doing what you wanted, so remove the "+ 10" and write the next test.

Credit with real value

Now make sure you can credit the account with a real value.

Use the amount £12.34, although the currency is obviously irrelevant here.

Once again, create a test and add it to the test suite. I show the test as follows:

public function testCreditWithRealValue():void{     var account:Account = new Account();;     assertEquals("Expecting account balance with           pounds and pence.", 12.34, account.getBalance()); }

Again, you create a new instance of the Account class, call the credit method (which now does exist) and pass in a value of 12.34. Therefore, you expect a balance of 12.34 returned.

Finally, this test passes for the first time. With something as simple as this (considering our other tests are also in place) I don't think you need to double check it by making it fail. On with the final test.

Credit to three decimal places (fractions of a penny)

In the next scenario, the bank has specified that it will allow account credits which include fractions of a penny, but it will always round these amounts down and keep the extra (they are a bank after all); so if you put in thirty seven and a half pence, the account would be credited with 37 pence. Here, you simply check a number to three decimal places.

Write the test (see below) and add it to the test suite (not shown):

public function testCreditWithRealValueTo3DecimalPlaces():void{     var account:Account = new Account();;     assertEquals("Expecting account balance of 1.23",               1.23, account.getBalance()); }

Run the application and see it fail. Good. There is enough code in place for the application to compile already, but of course you are expecting a rounded-down figure, and the current credit method is not set up for that, so you get the following TestRunner error:

Error: Expecting account balance of 1.23 - expected:<1.23> but was:<1.234>

That's exactly what is expected. Now you write enough code to make it pass, which means changing the credit() method to round off the amount. Change it to look like the following (changes in highlight):

public function credit(amount:Number):void{     var rounded = Math.floor(amount * 100)/100;     _balance += rounded; }

If you run the test, it passes. Notice that Flex Builder warns you that you forgot to give therounded variable a Type definition. To do that, change the code to:

var rounded:int = Math.floor(amount * 100)/100; 

Run the application and...

Hang on a minute. We seem to have broken a couple of tests.

Let's look at the first one:

Running the testCreditWithRealValue test

Figure 4. Running the testCreditWithRealValue test

The testCreditWithRealValue was passing before, so what did we do to break it? Well as you can see, the test was expecting a real value of 12.34 but it only received 12.

In a moment of distraction, we typed the variable incorrectly as int, and of course integers arewhole numbers. In this case my contrived example was pretty obvious, but it shows how changing or implementing new functionality can break earlier code, and how TDD alerts you to that fact instantly.

All you need to do to fix this particular error is to type our variable as Number:

rounded:Number = Math.floor(amount * 100)/100; 

Now run the application and all tests pass.

Let's look at the testCreditWithRealValue test again for a moment... luckily you chose to use decimals in the "real value" test. Obviously an integer is a valid "real value" too, and if you had just used an integer, you wouldn't have spotted this error so easily. It is important to spend a moment naming our tests accurately, and more importantly, ensuring that you can't break a test down further in to smaller tests. One of the XP maxims is "Test until fear turns to boredom". TDD is great, but it's not an instant solution to all your problems. I wanted to show both how useful it can be, and how thin the distinction can be between useful feedback and no feedback at all.