Blogs

My recent assignment at Albumprinter gave an opportunity to play with flex testing tools available out there. Coming back to serious flex development after more than a year was a pleasant surprise. The state of flex when I last did something on it was for sure not “mature”. There weren’t many frameworks around.

But things have changed a great deal since then. Not only do we have frameworks implementing MVC (Cairngorm) but also some standard extensions (UM extensions) to those frameworks, we also have spring like IOC frameworks (Prana) for Flex.

Maybe I will keep the discussion about these frameworks out for now, as they each deserve a dedicated blog. Here I would like to share my surprise with the testing tools available for flex:

FlexUnit
– As the name suggests, this is a sibling to XUnit frameworks, and doesn’t really has any learning curve for anyone coming from JUnit or CUnit genre.

A typical test would look like:

public function testDeposit():void {
   	var bankAccount:BankAccount=new BankAccount();
   	bankAccount.deposit(50);
   	assertTrue("Balance on a new account after 50 deposit is 50",
                            bankAccount.getBalance() == 50);
   	bankAccount.deposit(25);
   	assertEquals("Balance after 50 deposit and another 25 deposit is 75",
                          75,bankAccount.getBalance());
  }

public function testWithdraw():void {
   	var bankAccount:BankAccount=new BankAccount();
   	bankAccount.deposit(100);
   	bankAccount.withdraw(50);
   	assertTrue("Balance on a new account after 100 deposit and a 50 withdraw is 50",
                          bankAccount.getBalance() == 50);
  }

And then we add a testrunner (similar to JUint Runner plugin of eclipse) to the main mxml:

<flexunit:TestRunnerBase id="testRunner" width="100%" height="100%" />

We add the test suite to the above test runner like this:

private function onCreationComplete():void
{
  	testRunner.test = createSuite();
  	testRunner.startTest();
}

// Creates the test suite to run
private function createSuite():TestSuite {
  	var testSuite:TestSuite = new TestSuite();

  	testSuite.addTestSuite( BankAccountTest );

  	return testSuite;
}	

On running, this might look like this:

dpUInt/fluint
Though FlexUnit is a great advance for serious unit testing of presentation layer, it lacked some features like easy support of asynchronous tests. This becomes a limitation, given that flex finds application in many event-driven asynchronous paradigms. Although there is support for async operations in FlexUnit, they need some work. To resolve this bottleneck “digital primates” introduced dpUInt – The Digital Primate Unit and Integration testing frameworjk and with their first official release renamed it to fluint. This looks very similar to FlexUnit in use, but is not an extension of the same.

Flex Monkey
FlexMonkey is a unit testing framework for Flex apps that provides for automating the testing of Flex UI functionality. If you are already in love with Selenium, you can think of FlexMonkey as “Selenium for Flex”. FlexMonkey can record and play back Flex UI interactions, and generates ActionScript-based testing scripts that can easily be included within a continuous integration process. It uses the Flex Automation API and was created by adapting Adobe's sample application, AutoQuick.

FlexMonkey has been donated to the Flex community by Gorilla Logic, who developed FlexMonkey because of their belief that only a monkey would develop code without being able to automate their unit testing.

Essentially you use it in 3 modes:

1.	Record user interactions and play them back as required.
2.	Write unit tests to test UI functionality and play them programmatically.
3.	Probably the most interesting aspect is to combine the above two: Manually do the user interactions and record it.
This automatically generates test case in action script!
Just use this generated code in your testing environment and adapt it as required!

Additionally it has a “flex spy” tool that helps investigate the container hierarchy. This comes handy when you start anew on an already-developed product. This tool helps to quickly understand the code and the flex components used.
It’s not just simple but also exciting to look at, when its in action. I started with this more as a flex toy to play around, but pretty soon, I realized its worth – A Monkey Test I had implemented to demonstrate a new feature broke after a week. It immediately indicated that the new features under development were affecting the existing ones. Monkey helped us to “fail early”, as is the spirit of Agile, and thus saved some time and resource for later-on “hot fixes” As much as its nice to look monkey-in-action, its also difficult to capture it in snapshots. But hereunder, I try to give a sample run of a Monkey test having two test cases:

Flex Cover
This is a test coverage tool. It not only gives the percentage coverage of lines and branches of code, but also updates itself on-the-fly at run time – as the test cases run, it updates its percent figures. It also marks the code that was not covered.
Additionally, unlike clover test reports it specifically gives the number of times each branch was executed. For example, while clover indicates that a particular “if” statement is RED as it was called 2 times but one of the branches was not called even once - it doesn’t really indicates exactly which branch (if-branch or else-branch) was not executed. (As per my limited knowledge of clover, may be this is configurable; in that case; excuse me for my limited exposure to clover). The Flex Cover in above example explicitly mentions the number of times each branch was executed.

It incorporates a modified version of the AS3 compiler which inserts extra function calls in the code within the SWF or SWC output file. At runtime, these function calls send information on the application's code coverage to a separate tool; The modified compiler also emits a separate "coverage metadata" file that describes all the possible packages, classes, functions, code blocks and lines in the code, as well as the names of the associated source code files.

For sure, its early days and I have been using these tools only for about a week now. But definitely its exciting times in flex world, and I’ll look forward to exploring more. Will keep you guys posted!

Abhishek.

As I got introduced to Flex world some times back, I started using Flex Builder as an IDE, a product from Adobe on top of Eclipse platform. I assumed that it'll provide all the basic features available in Eclipse for Java, but I was wrong. Flex Builder is in nascent phase from tooling point of view. Just to refresh your memories, Flex Builder lacks some of the following Eclipse features.

1. Support for generating getters-setters automatically.
2. Support of templates for creating constants.
3. Organize imports. If some type has not been included already, organize-import should do that.
4. Better refactoring support. Right now refactoring is just limited to renaming and you start missing real sense of refactoring in terms of creating new methods etc.
5. Sometimes you may want to create your own templates for creating ASDoc instead of doing it from the scratch all the time
6. Formatting ActionScript/Flex files

I did some research on internet and found some options to resolve these problems.

Eclipse Monkey

Eclipse Monkey currently is a part of Eclipse Dash project. It is proposed to be split from Dash to make it full-fledged project in itself. It's a very powerful tool. Instead of extending Eclipse platform through creating plugins, you can extend Eclipse functionality through some scripting. Eclipse Monkey uses the Mozilla Rhino Javascript interpreter at its core. You guessed it right, scripting couldn't have been easier for Eclipse than the way it does with Monkey using Javascript.

Eclipse Monkey can be used to create getters and setters in ActionScript in automated fashion. You may want to take a look on a ~eokyere blog to see how Monkey is used to create getters and setters. As I searched some more available Monkey scripting resources, I found more examples and one of them satisfied my problem no 2 also.

If you have already downloaded and executed Monkey scripts on your Eclipse platform, you may have realized how powerful this Scripting tool is for Eclipse. You can create a lot of scripting based tools to enhance productivity without creating specialized plugin.

FDT ActionScript Editor

For rest of the problems mentioned above, I tried many options but somehow they didn't provide desired outcome. However one ActionScript based editor FDT comes very close. It supports most of features mentioned in the list and is certainly a better choice from ActionScript editor point of view. However it's not free and sometimes I wonder why somebody will invest yet another €599 to buy this tool if he already has Flex Builder. Flex Builder is a defacto tool for Flex based development whereas FDT mainly focuses on ActionScript based programming. FDT doesn't support MXML yet.

No wonder that we come to conclude that Flex Builder has a lot to catch up in terms of enhancing its tooling for Flex developers. However the tools I just mentioned come a bit close in providing the required support.

About 2 years ago I first heard the term "technical debt" from one of my coworkers. Well, I heard technical depth instead of debt first, which clearly did not help me see why it was such a great term for crappy code and quick and dirty solutions.

It was not until a week ago when I had a chat with another coworker who casually pointed out to me that you pay interest on any outstanding technical debt you may have. Just like real debt. Any time you are adding something to a code base that has technical debt, you can not help but increase it. You just can not quickly add good and proper code to a code base that has a lot of technical debt. Thus the interest.
This is a great selling point to clean up code early in the project and invest time to fix things now, instead of 6 months down the line when the project is almost over.

One of the projects I worked with recently was a great example. It was a project that had been underway for a long time and no real significant time was spend on cleaning up the code and keeping it clean. They were under a lot of pressure to deliver more functionality. This pressure made them choose suboptimal solutions to the problems they had, increasing their technical debt even further. Until a point where they were not even able to deliver proper solutions and all subsequent solutions were just increasing the debt. This is the interest my coworker was talking about. They finally realized what was going on and they are now spending weeks with more than half the team trying to pay off that debt.