• What are you using (FlexMonkey, FlexUnit, Mercury QTP, Selenium, RIATest, FunFX, etc)?
• Have you run into major pitfalls with your Flex testing?
• Are the tools you are using allowing your team to achieve your testing goals?
• How would you rate the state of testing in Flex development?

Thanks! I look forward to hearing from you.

FlexMonkey is an open source Adobe AIR application used for testing Flex and AIR applications.  It provides the functionality to record, playback, and verify Flex UI interactions.  It also generates ActionScript / fluint tests that you can easily include within a continuous integration environment.

Who is FlexMonkey for?

Like many in the Flex community, we came to Flex development after many years of developing traditional web applications, where there are multiple tools that allow a developer to simulate a UI client for testing (like HTMLUnit).  For testing our Flex user interfaces, we had a strong desire to continue using this paradigm for our developer level testing.

As software consultants, ensuring quality is an important part of what we do.  So, we created FlexMonkey to fill the gap between a unit test and what’s really needed to ensure quality (and protect against regression) when developing user interfaces.  While we initially created FlexMonkey for developers, many in the FlexMonkey community have found it just as valuable for use in creating QA / Functional tests.

So, we believe that FlexMonkey is useful to both software developers and quality control engineers on Flex development projects.

So, what’s so game changing about it?

If you ask Mike Labriola (one of the Fluint/FlexUnit 4 guys), ‘How do I unit test my Flex user interfaces?’  He will quickly respond, ‘You don’t.’  He won’t tell you this because he doesn’t believe in unit testing (as I can assure you that he strongly believes in Unit Testing), but because there are parts of a user interface that cannot be sufficiently tested with unit tests.

So, as we jump into the reasons why FlexMonkey matters for you, I’ll note that we do not believe that FlexMonkey replaces the need for traditional unit tests.  There are still parts of a Flex application that are best tested this way (e.g. service clients, business logic, etc.).  If you are building a framework, it’s likely that the majority of your testing will be done through unit tests, but if you are focusing on features and functionality you will likely be able to achieve upwards of 80% of your testing goals with FlexMonkey.  Nevertheless, here are the high level places where FlexMonkey changes the game:

1. FlexMonkey fills the gap left between unit testing and a truly successful test suite,  as it provides a tool for doing developer level functional tests that replace traditional unit testing activities that developers perform in other tiers of application development.
2. FlexMonkey allows developers to write their user interface code in the most natural way. Typically, when developing a user interface application without a tool to simulate a client of the running application, the code has to be written differently to support testing.  This often leads to many unnatural acts, which can be avoided when using FlexMonkey.

   For the Java folks, I like to bring up the SpringFramework here, as it provides us with a powerful example of a framework that largely succeeded because it allows developers to write their code in a natural way.  Over the long run, the frameworks and tools that make it possible for developers to work in the most natural way will always win out.

   Tools like FlexMonkey are able to facilitate this simply through the paradigm they provide for testing user interfaces, as they allow developers to test applications without any knowledge of the underlying code.

3. Cost. FlexMonkey is free.  So, even though it’s not a perfect tool, it does enable one to build and deploy a successful test suite, a task that is extremely difficult and costly in Flex development without FlexMonkey.

You can find the FlexMonkey project at: http://flexmonkey.gorillalogic.com/

FlexMonkey is built and open-sourced by Gorilla Logic, Inc.

Now, they are attempting to expand from just a framework to some sort of Flex MVC framework think-tank. Yakov Fain’s reaction to this is priceless:

First, let me ask Java developers a question. Imagine that one day you wake up and read the following announcement, “As of today, Spring framework is the foundation for delivering of successful J2EE projects. In contrast to earlier versions, many parts apply across frameworks. So, if you are using Struts, JSF, and especially Tapestry, just forget about all these complex to pronounce names. From now on, no matter what framework you use, you are actually using Spring’.

Some of you would think, “Yakov is either out of his mind or is writing this blog sitting in one of the coffeshops in Amsterdam”. Wrong! I’m just reading an announcement about the upcoming release of the popular Adobe framework Cairngorm 3: http://opensource.adobe.com/wiki/display/cairngorm/Cairngorm+3

When I first saw Cairngorm (post), it was easy to understand what they were trying to do, as the framework is so heavily influenced by the original version of Struts and the Core J2EE Patterns. Unfortunately, Struts was barely a fit for the original problems it was attempting to solve, and are completely inappropriate for building client-side applications within a real runtime. Struts used an adaptation of the MVC pattern called MVC2/Model 2, which was created to deal with building user interface within request/response model. This model is completely at odds with building a rich Internet application.

So, obviously, I find the move to hold Cairngorm up as a template for architecting Flex applications a bit concerning. Beyond that, one of the other things in the Java community that never proved to bring fruit was the desire to standardize anything and everything, which this idea seems born out of.  I am actually foggy at best with what they are trying to accomplish, and find it completely bizarre that they would try and morph a framework into this “thing.”  Do we really need some sort of Flex specific think tank on a long established pattern?  Also, it seems very bold to attempt to group the work of so many others under their umbrella.

Is this just an attempt to keep the brand name relevant of a framework whose time has come and gone?

Here is my write up: http://www.infoq.com/news/2009/11/flash-10.1-and-air-2.0

Honestly, this episode makes me wonder if our recipe for Drunk on Software success is more of Chet and less of James and I.

Original Post

Additional Resources:

• Component for Role Based Permissions in Flex
• Flex Security Component Updates
• Project Home

FlexMonkey Resources:

• FlexMonkey Project Page
• FlexMonkey project blog
• Adobe Dev Center Article: Testing Flex applications with FlexMonkey 1.0

You can find the original post here: http://www.drunkonsoftware.com/2009/07/14/episode-14-flexmonkey/

FlexMonkey Resources:

• FlexMonkey Project Page
  
• InfoQ News Posts
• DrunkOnSoftware: Stu Stern Interview
• DrunkOnSoftware: Release Party
• InfoQ: Stu Stern 2008 Interview
• FlexMonkey project blog
• InfoQ Article: FlexMonkey brings unit testing to Flex user interface developers
• Adobe Dev Center Article: Testing Flex applications with FlexMonkey 1.0

For more information on Gorilla Logic’s Flex services check out: http://www.gorillalogic.com/what.development.services.flex.html

So, moving forward by pretending that no one will disagree with that assertion, here is the overview of what would be in my perfect Flex application development framework:

• Separation of Concerns (SoC):

  In Flex development, there is a need for something outside of the core framework to help developers adhere to a separation in the application code.  In reality it is not the most difficult or interesting part of the problem, but would likely be a part of any complete third-party framework.   I personally prefer the Swiz dependency injection approach for this.  Also, there are likely a number of interesting things one could add on top of a dependency injection foundation, as we have seen with the SpringFramework in Java.

  Looking at the Swiz implementation, one can also conclude that the underlying platform needs to grow so that this can be supported in a more native way and increase the possibility that greater leverage can be gained from introducing dependency injection to Flex applications.

• Client Side Data Management (think client side Hibernate):

  RIA introduced (or re-introduced) the notion of client side data / state.  In traditional page based applications, the developer never had to consider this possibility, as all state is kept and tracked on the server.  With advanced RIA features, state is often changed on the client, but not immediately sent back to the server.  This introduces a number of challenges in managing data state between the client and the server.  Thus, there is a need for infrastructure to support data synchronization between the client and server.

  Both LiveCycle Data Service (LCDS) and Clear Toolkit include features that help the developer with this to a certain extent, but they rely on the specific server implementations.  In my perfect imaginary world, this would all be done client-side agnostic of what server is providing the data so that one could use it regardless of what technology is providing the data.

  This may even be coming in the next version of Flash Builder:

  “Of course, data-centric applications are about more than just binding operations to components. Flash Builder lets you enable client side data management for your services, allowing on-demand fetching of data for easy and efficient scrolling through large collections of data; change tracking, allowing users to undo actions, and automating the common CRUD (create, read, update, & delete) functions that usually need to be hand-coded. The results are applications that deliver users a richer experience than is possible with ordinary HTML front ends.”

• Security:

  In any enterprise application, there are security considerations at multiple levels. There are a number of methods and strategies for dealing with authentication, but not many Flex tools for addressing authorization. In the simplest form, one can break out authorization into the following categories: service/method level, data level, and filtering what each user can view on the screen. Securing services and data pretty much have to be handled on the server, but something is necessary to control what the user sees on the client.

  There are not many libraries I know of for implementing this common requirement. My current preference is my Chimp component for doing this declaratively through Flex metadata. Many just deal with this manually in each component, others monkey patch to add filtering logic on UIComponent or within View States. Ideally, features for dealing with this challenge would make it into any complete third-party framework.

• Global Event Bus:

  In Mate, basically every event is handled through the Mate event bus. Having a global event bus can invaluable in implementing a number of RIA features. Yet, handling every single event this way seems a bit odd to me. I think Flex events can be broken into four categories:

  Component Events: These are events that are only omitted and handled inside the component. Think of a component that has children and they need to communicate between one another.
  Local Events: These events are omitted by components that can be handled by within the context that the component is used.
  Global & Data Change Events: Events that any arbitrary part of the system may want to be notified of when they happen, such as the user profile has changed.

  So, in my mind, the bus is a necessary part of the perfect Flex framework, but shouldn’t be used for handling all events in the system.

Those are my top requirements for the perfect third-party Flex framework. I am sure there are a number of others that it would make sense to add to the list.

In working through this post, I concluded that there is too much focus put into third-party frameworks with Flex. The items I outlined are missing gaps that need to be met with third-party frameworks, or hopefully by the underlying platform someday, but they are not the most challenging things one will encounter when building enterprise Flex applications.

The biggest challenge for Flex applications of any scale is the quality Flash Player virtual machine. The Flash Player has to get faster, better at dealing with memory consumption, and garbage collection. Flex is a good platform for building rich Internet applications, but like any emerging technology it will have to mature to continue to gain adoptions and keep the current developers.

1. Since the language around browser standards is very feel good, with terms like “open web,” I think it is often lost how much big companies, such as Google and Mozilla, stand to gain if developers validate their assertions around browser standards. In all reality, the open web vendors are no different than the vendors providing “third party runtimes,” they want / need people to use their platforms.
2. The “open web” never existed. Let’s take a look at a quote from Ian Hickson, HTML 5 specification co-editor and Google employee:
   

   “It would be a terrible step backward if humanity’s major development platform [the Web] was controlled by a single vendor the way that previous platforms such as Windows have been.”

   Not only does the language seem a bit dramatic to me, but I think there is little risk of this happening (outside of the standards). Historically browser standards have been the main catalyst in bringing us down to the lowest common denominator in web development. We have all worked on projects where the management decided to just build the application to work in IE because the browser standards are unreliably implemented across browsers.

The reality is that the RIA space is currently experiencing wonderful competition across vendors (Flash, Silverlight, JavaFX) with applications being built and deployed on a number of different platforms. Frankly, none of the current platform advancements that are making developers lives easier have come from standards based implementations.