Archive for the ‘programming’ Category

Fluint 1.1.1 ready to be released

Brian LeGros | April 29th, 2009 | programming  

After a busy couple of months, I’ve finally gotten off of my ass and decided to do the integration for Fluint 1.1.1 and created the new branch for Fluint 1.2. We’re in the process of getting the artifacts into Google Code, but the release tag is in Subversion now for those who are interested. In this release we had a couple small fixes:

  • Issue #34 – Assets are not located in net/digitalprimates/fluint folder
  • Issue #35 – Can’t find TestResponder
  • Issue #37 – Air Test Runner needs better error handling
  • Added new target to ant build for building the airtestrunner as an .airi file (target => “airtestrunner-intermediary”)
  • Added flex builder metadata files to the samples project

I’ve already added my stubs for HTTPService and RemoteObject to the 1.2 branch for those who want to play around with them. Matt Hughes’ sequence improvements will also be included in 1.2 once I figure out where they ended up. For 1.2 I’m hoping to add some documentation for the wiki to address some really early issues as well as #28. In terms of bug fixes and new features, I’m hoping to tackle issues 32, 38, 41, 42, 44, 45, and 46 (#44 being the highest priority).

With a new baby coming in May, I’m unsure of my schedule, but I’m gonna do my best to get what I can ready (=who knows). In the mean time, kick the tires for us and let us know if there are any issues with 1.1.1.

Using Stubs for HTTPService and RemoteObject in Flex

Brian LeGros | February 21st, 2009 | programming  

UPDATE: I’ve finally created a project for these stubs on GitHub @ http://github.com/blegros/flexRpcStubs. Please consider this code more up to date then what follows below.

Recently I’ve been working on producing stub versions of HTTPService and RemoteObject for some integration tests I’m writing. If you haven’t worked with the concept of a stub before, think of a stub a re-implementation of an object created to produced canned answers to calls made to it during a test (borrowed from Mocks aren’t Stubs). A stub is intended to be purposefully ignorant to everything but what is being asked of it in a test. If you’re familiar with the concept of a mock object, a stub can be considered a specialization of a mock object that has no expectations to manage rather only return values. In a lot of circles the term mock and stub are used interchangeably, but I think the difference is important to note. If you’re interested more in the subject, come and see my presentation at FlexCamp Miami on March 6th, 2009.

Typically, in the case of integration testing, stubs are used to impersonate objects which have direct contact with resources external to your application, or component. In the context of most programming langauges I’ve worked with, these are typically classes built into extension libraries for the language (e.g. – JDBC, log4j, javax.mail, etc). In the context of Flex, services are the primary sets of classes that we end up wishing we could stub out. Unfortunately, the need to stub these types of classes can introduce some complexities, especially without a good mock object framework, because very rarely are the interfaces to these classes simple enough for a developer to impersonate on the fly (i.e. – inline in a single test). In the Java world, frameworks like Spring will create helper objects for testing to supplement these needs (e.g. – MockHttpSession and AbstractTransactionalJUnit4SpringContextTests).

In Flex, I haven’t really found a great set implementations for stubs yet, so this weekend I threw together a first draft of working stub classes for HTTPService and RemoteObject in AS3 using the Flex SDK 3.2. I’ve been using variants of these for my testing and so far, so good. Anyone interested in stubbing WebService, can proabably create a similar model to what I’ve done in RemoteObjectStub and be successful. Each stub is type-safe and adds the following properties for configuration to their base classes:

  • delay : Number – Default: 1000 – Number of milliseconds to delay calling registered responders and dispatch the appropriate events for the stub.
  • result : Function – The method used to map result, or fault, objects to specific signatures of send (for HTTPService) or a method name (for RemoteObject). If passed an object deriving from type mx.rpc.Fault, a mx.rpc.events.FaultEvent will be dispatched rather than a mx.rpc.events.ResultEvent.
  • fault : Function – A sugar method that will take in a faultCode, faultString, and faultDetail to create a mx.rpc.Fault and delegate to result().

Each class also supports the dispatching of the appropriate events to mx.rpc.AsyncToken objects as well as the stub instances themselves, just like their base classes. Here is a example of using HTTPServiceStub, in place of HTTPService, in a test case written using fluint:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
public class ClassWithHTTPServiceDependencyTest extends TestCase
{
   private var _classBeingTested : ClassWithHTTPServiceDependency;
   private var _stub : HTTPServiceStub;
 
   override protected function setUp() : void
   {
      _classBeingTested = new ClassWithHTTPServiceDependency();
      _stub = new HTTPServiceStub("http://thisisntarealdomain.com");
      _stub.delay = 500;
      _classBeingTested.service = _stub;
   }
 
   public function testSendWithTokenResult() : void
   {
      var result : Function = function (event : DynamicEvent, passThroughData : Object) : void
      {
         assertEquals("GOAL!", event.payload);
      };
 
      _stub.result(null, "GOAL!");
 
      _classBeingTested.addEventListener("success", asyncHandler(result, 2000));
      _classBeingTested.someMethodUsingHTTPService();
   }
}

In the above example, the behavior being tested is that when a ResultEvent is dispatched to ClassWithHTTPServiceDependency, it dispatches its own mx.events.DynamicEvent with a reference to the result property of the ResultEvent in its payload property. Please note, the call to send() is being made inside of someMethodUsingHTTPService() but could really be made anywhere inside of the object, we don’t care since the stub can impersonate HTTPService.

The implementations for the HTTPServiceStub and RemoteObjectStub are something I hope to get feedback on and maybe get included in fluint or mock-as3, although I’m sure Drew can think of sexier implementations. Below is the source for anyone who is interested in giving them a go to see if they can help your testing process. I have a few unit tests for each as well, so if anyone’s interested, just let me know and I’ll post that code as well.

Happy coding and here’s to these not working and failing you miserably …

HTTPServiceStub.as

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
package net.digitalprimates.fluint.stubs
{
   import flash.events.TimerEvent;
   import flash.utils.Dictionary;
   import flash.utils.Timer;
 
   import mx.rpc.AsyncToken;
   import mx.rpc.Fault;
   import mx.rpc.IResponder;
   import mx.rpc.events.AbstractEvent;
   import mx.rpc.events.FaultEvent;
   import mx.rpc.events.ResultEvent;
   import mx.rpc.http.HTTPService;
 
   /**
    * Idea borrowed from Sonke Rohde @ http://soenkerohde.com/2008/10/conditional-compilation-to-mock-with-swiz/
    **/
   public class HTTPServiceStub extends HTTPService
   {
      private var _resultData : Dictionary;
 
      //default num of milliseconds to wait before dispatching events
      //don't put too low otherwise your token responders may not be registered
      public var delay : Number = 1000;
 
      private var token : AsyncToken;
      private var parameters : Object;
 
      public function HTTPServiceStub(rootURL : String = null, destination : String = null)
      {
         super(rootURL, destination);
         _resultData = new Dictionary();
      }
 
      public function result(parameters : Object, data : *) : void
      {
         _resultData[parameters] = data;
      }
 
      public function fault(parameters : Object, code : String, string : String, detail : String) : void
      {
         var fault : Fault = new Fault(code, string, detail);
         this.result(parameters, fault);
      }
 
      override public function send(parameters : Object = null) : AsyncToken
      {
         return configureResponseTimer(parameters);
      }
 
      private function configureResponseTimer(parameters : Object) : AsyncToken
      {
         token = new AsyncToken(null);
         this.parameters = parameters;
 
         //use a time to give time for the caller to map responders to the asyncToken
         var timer : Timer = new Timer(this.delay, 1);
         timer.addEventListener(TimerEvent.TIMER_COMPLETE, handleTimer);
 
         timer.start();
 
         return token;
      }
 
      private function handleTimer(event : TimerEvent) : void
      {
         //clean-up
         event.target.removeEventListener(TimerEvent.TIMER_COMPLETE, handleTimer);
 
         //loop over all responders to emulate a successful call being made
         for each(var responder : IResponder in token.responders)
         {
           var response : Function = isFaultCall(parameters) ? responder.fault : responder.result;
           response.apply(null, [generateEvent(parameters)]);
         }
 
         //dispatch event to service just in case token wasn't used
         dispatchEvent(generateEvent(parameters));
      }
 
      private function isFaultCall(parameters : Object) : Boolean
      {
         return (_resultData[parameters] is Fault);
      }
 
      private function generateEvent(parameters : Object) : AbstractEvent
      {
         if(isFaultCall(parameters))
         {
            return new FaultEvent(FaultEvent.FAULT, false, true, _resultData[parameters]);
         }
         else
         {
            return new ResultEvent(ResultEvent.RESULT, false, true, _resultData[parameters]);
         }
      }
   }
}

RemoteObjectStub.as

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
package net.digitalprimates.fluint.stubs
{
   import flash.utils.Dictionary;
 
   import mx.rpc.AbstractOperation;
   import mx.rpc.Fault;
   import mx.rpc.remoting.RemoteObject;
 
   public dynamic class RemoteObjectStub extends RemoteObject
   {
      private var _resultData : Dictionary;
 
      //default num of milliseconds to wait before dispatching events
      //don't put too low otherwise your token responders may not be registered
      public var delay : Number = 1000;
 
      public function RemoteObjectStub(destination : String = null)
      {
         super(destination);
         _resultData = new Dictionary();
      }
 
      public function result(methodName : String, args : Array,  data : *) : void
      {
         if(!methodName || methodName.length == 0)
         {
            throw new Error("Cannot use null or empty method names in RemoteObjectStub.");
         }
 
         if(!args)
         {
            args = [];
         }
 
         if(!_resultData[methodName])
         {
            _resultData[methodName] = new Dictionary();
         }
 
         _resultData[methodName][args.toString()] = data;
      }
 
      public function fault(methodName : String, args : Array, code : String, string : String, detail : String) : void
      {
         var fault : Fault = new Fault(code, string, detail);
         this.result(methodName, args, fault);
      }
 
      override public function getOperation(name : String) : AbstractOperation
      {
         return new OperationStub(this, name, _resultData[name]);
      }
   }
}
 
import mx.rpc.AsyncToken;
import net.digitalprimates.fluint.stubs.RemoteObjectStub;
import mx.messaging.config.ServerConfig;
import mx.rpc.Fault;
import flash.utils.Dictionary;
import mx.rpc.remoting.Operation;
import mx.rpc.remoting.RemoteObject;
import flash.events.TimerEvent;
import mx.rpc.events.AbstractEvent;
import mx.rpc.events.FaultEvent;
import mx.rpc.events.ResultEvent;
import flash.utils.Timer;
import mx.rpc.IResponder;
 
internal class OperationStub extends Operation
{
   public var _resultData : Dictionary;
 
   private var token : AsyncToken;
   private var args : Array;
 
   public function OperationStub(remoteObject : RemoteObject, name : String, resultData : Dictionary)
   {
      super(remoteObject, name);
      _resultData = resultData;
   }
 
   override public function send(... args:Array) : AsyncToken
   {
      return configureResponseTimer(args);
   }
 
   private function configureResponseTimer(args : Array) : AsyncToken
   {
      token = new AsyncToken(null);
      this.args = args;
 
      var stub : RemoteObjectStub = RemoteObjectStub(service);
 
      //use a time to give time for the caller to map responders to the asyncToken
      var timer : Timer = new Timer(stub.delay, 1);
      timer.addEventListener(TimerEvent.TIMER_COMPLETE, handleTimer);
 
      timer.start();
 
      return token;
   }
 
   private function handleTimer(event : TimerEvent) : void
   {
      //loop over all responders to emulate a successful call being made
      for each(var responder : IResponder in token.responders)
      {
         var response : Function = isFault(args) ? responder.fault : responder.result;
         response.apply(null, [generateEvent(args)]);
      }
 
      //send the result event to the RemoteObject as well
      service.dispatchEvent(generateEvent(args));
   }
 
   private function isFault(args : Array) : Boolean
   {
      return (_resultData[args.toString()] is Fault);
   }
 
   private function generateEvent(args : Array) : AbstractEvent
   {
      if(isFault(args))
      {
         return new FaultEvent(FaultEvent.FAULT, false, true, _resultData[args.toString()]);
      }
      else
      {
         var result : * = _resultData[args.toString()];
         return new ResultEvent(ResultEvent.RESULT, false, true, _resultData[args.toString()]);
      }
   }
}

UPDATE: – Thanks to Joel Hooks for exercising these a bit more and figuring out a GC issue with the timer that provided some flukely behavior. The above code now supports his fixes in both HTTPServiceStub and RemoteObjectStub. I’ve also run my unit tests against the latest Flex 4 beta and everything passed. Looks like these may be more useful as we start to use Flex 4.

Testing Tools for Flex

Brian LeGros | February 20th, 2009 | programming  

Over the last few weeks, while preparing my presentation for FlexCamp Miami a bit more, I have run into quite the plethora of tools to help developers test their Flex applications. I thought I’d take some time to break down what types of tools are available to help us out.

Unit Testing Frameworks

Mock Object Frameworks

Other useful libraries

My favorite combination right now is fluint, mock-as3, hamcrest-as3, and asx. Although asmock supports type-safe mocking, I’m not a big fan of the record/replay model; for now I’m gonna stick with mock-as3 and wait until it supports type-safe mocks (<cough>loom integration<cough>. I’ve also found a major need for stubs when classes in my integration tests depend on HTTPService and RemoteObject. Sometimes its tough to mock out these classes because of complex interfaces these objects maintain, so I’ve come up with a pretty cool way of handling this. Hopefully I can publish the sample code here in the next few days for those who are interested.

I’d also like to give props to a couple people I’ve been working with in the community: Michael Labriola, Max Porges and Drew Bourne. Mike is working tirelessly to bring a more modern unit testing framework, a la JUnit 4 + more, to Flex via fluint along with tons of other initiatives. mock-as3, hamcrest-as3, and asx are all APIs that Drew has written; hamcrest-as3 alone is going to be providing some really powerful integration for assertions in unit testing frameworks. Max has been chipping away at the ABC spec with loom for months now, and once finished it’s going to provide a lot of great potential for more mature tooling/libraries in the Flex world … think AOP. Each of these code-bases are intuitive, easy to use, and were some of the biggest pieces missing from the Flex testing world until now. Keep up the great work guys! With any luck, we may soon have the tools we need to be as productive as developers in almost every other language out there.

Fluint 1.1.0 Released!

Brian LeGros | February 12th, 2009 | programming  

Over the last few months, I’ve been working with Michael Labriola on the next minor version release of Fluint. Well, this evening Michael and I put the finishing touches on release 1.1.0. This release brought all of the changes I made to get Fluint working at the office for our CI process to the community. There are a couple of cool little gems that I think will be helpful for some:

  • Separation of failures and errors in test reporting (visual and XML).
  • XML compliant output with most CI servers as well as the JUnitReport task in Ant and the Surefire Reporting plugin in Maven.
  • Support in the Ant task for truly headless executions of the AIR Test Runner via xvfb-run.
  • Support for relative paths in the Ant task and AIR Test Runner.
  • Better error handling for non-compliant modules loaded into the AIR Test Runner.
  • LogBook integration for debugging
  • A big folder re-organization and Ant scripts to support developers when they need specialty builds.
  • Agreed upon a branching and tagging strategy so the community can have stable snapshots of source to build.

We probably should put together a ChangeLog wiki page, so that may be available soon. We did a few updates to the wiki, so stop by the Google Code site and check out the changes. Also, provide feedback on the discussion list, if there are features you’d like to see implemented, bugs that you find, or just general questions you need help with. People are great about helping on the list, so don’t feel discouraged.

This is my first major release of an OSS project that I’ve had code go into, so thanks to everyone who helped with the release, especially my wife for putting up with a lot of late nights. There is a lot more to come with Fluint over the next year that is going to be really exciting. Look for announcements during my presentation at FlexCamp Miami and on the discussion mailing list. Hope you enjoy the new release!

Which assertions do you use in unit tests?

Brian LeGros | February 6th, 2009 | programming  

Over the last few days, I’ve decided to start putting some time into adding some new assertion functions into fluint. Here are a few that I was thinking of adding:

assertRegExp(expected : RegExp, actual : String) : void
assertArraysEqual(expected : Array, actual : Array, compare : Function) : void
assertDictionariesEqual(expected : Dictionary, actual  : Dictionary) : void

Along with each of these, their boolean counterpart would also be available (i.e. – assertArraysNotEqual). My question to other developers is, which assertions would you like to see available in your unit testing framework of choice? The way I figure, the more options available in the assertion stockpile, no matter how simplistic they may seem, the more explicit we can make our tests. Would anyone be interested in seeing some type of assertion using callbacks (i.e. assertReturnsEquals(actualCallback : Function, args ..rest, expectedResult)? Feels like a bit of a stretch, but it’s a datatype, so maybe it should be considered. Anything for events that may be useful?

What do you think?

Thanks for the invitation KSC

Brian LeGros | January 17th, 2009 | programming  

Big thanks to Doug, Bill, Jim, Mike, Don, Boss boss, and everyone else who joined me for my presentation on Continuous Integration and Flex at Kennedy Space Center. I ended up running around an hour and forty minutes giving an overview of the Adobe Flex domain and continuous integration as a whole. Thank you everyone for taking the time out of your busy schedules to tough through the presentation; I hope I have failed you all equally.

As promised, below are links to the materials from the presentation that I used as well as links to other resources you may find helpful.

Subversion – http://subversion.tigris.org/
Apache Ant – http://ant.apache.org/
Flex Ant Tasks – Use the libraries included in the Flex SDK 3.2 distribution
Fluint Library and Ant Tasks – http://code.google.com/p/fluint/
mock-as3 – http://code.google.com/p/mock-as3/
Hudson – https://hudson.dev.java.net/
Example Application and Component – http://brianlegros.com/blog/files/example_apps.zip
Slides – http://brianlegros.com/blog/files/slides.pdf

If you have any questions, please don’t hesitate email @ me at brianlegros dot com.

NOTE: The Fluint test runners and reports that you saw in my presentation were using a code base that has yet to be released by the Fluint team, but will be hopefully soon. We have a lot of great working going on at the Fluint project, so I’d encourage you all to check out the Google Code site as well as the Fluint mailing list.

Getting AIR to run headless for Continuous Integration

Brian LeGros | January 7th, 2009 | programming  

Here’s the thing about proof-of-concept projects, they always get the high risk technology questions out of the way, but they never manage to expose the stupid gotchas that are coming down the line when you go to make them into a reality. Case in point, unit testing in Flex and continuous integration. In my last post, I spoke about how I got flex-mojos, ant, fluint, and Hudson all playing nice together. Please preface the following with the fact that I’m a terrible server admin, so there may be work arounds for the roadblocks I ran into, I’m just not aware of them.

So when our team went to deploy the PoC, we decided to use Windows. Our hope was that with the lack of headless support in AIR, Windows would provide us access to a windowing system even when a user isn’t authenticated thanks to the dreaded LocalSystem account. As expected, I was able to get Hudson up and running and the AIR test runner was working without issue while running as LocalSystem. I then needed to integrate a series of CI builds which we put together to automatically release our components. All of sudden, I had the need for user specific settings to interact with putty, plink, and SVN, then LocalSystem failed me. I setup a special user to run the service hosting Hudson and placed that user into the Administrator group to start; I figured once I had it working again, I’d restrict its rights … <crickets chirping>. So when I had finally gotten the automatic release builds working with the new user, I re-ran one of my previous CI builds only to find that the build would hang when the AIR runner for Fluint was executed. After hours of pouring over a solution (I even tried this registry hack for the service with no success), I decided that Windows just wasn’t going to work.

I decided to give Linux a shot and I have to say I had much better results; I chose Ubuntu for my PoC due to its simplicity for guys like me. As a nice plus, all of the SSH/SVN woes I experienced disappeared because I had a native SSH client and integration was just easy. I still had the issue however of needing to run AIR in a truly headless mode. I started with some tips I found on the Fluint mailing list and was able to get Xvfb up and running as a service. Integration with the Fluint Ant Task didn’t pan out easily though, so I again looked for another solution. I did some digging and as it turns out a lot of the Java/Swing folks had to solve the same problems we’re having to solve now before Java gained the ability to run Swing apps headlessly. I found this post on xvfb-run and it did the trick. In fact it worked out so well, that I went ahead and integrated it into the Fluint Ant task as an option. Effectively I just had it execute the AIR application with the “-a” flag so sysadmins who are picky about how xvfb-run is used may not like the lack of granularity I’ve built in, but it’s working for us. I know that FlexUnit has a similar issue since the Flash Player can’t be run in a headless-mode either, so this may be a good feature to add to the FlexUnit Ant task eventually too. On a side note, my changes to Fluint are being reviewed right now and it looks like I may get my branch merged into the next release fairly soon for anyone who is interested in finding binaries.

We’re still working to deploy on a different Linux distro at the moment, but I think we’ve finally managed to mitigate the risk of running a Flex build on a CI server for the different variations we’ve thrown together. If you see another post from me really soon, you’ll know the edge of the PoC sword got me again … stupid sneaky sword.

Continuous Integration with Maven, Flex, Fliunt, and Hudson

Brian LeGros | December 17th, 2008 | programming  

Recently I was tasked with streamlining our build process at work so we could get a continuous integration (CI) server up and running. We use the common stack of technologies found in most Flex shops (basic SDK, some libraries, and Flex Builder) as well as Maven. I ran into some challenges getting our CI process to work as we wanted, so I figured I’d go through some of the gotchas I encountered.

On the build side of things, when I came on, Maven was already in place using flex-mojos. Now I’m a big fan of the simplicity that Ant brings to the mix, but the issue of dependency management being baked into Maven makes it extremely appealing; I do like Ivy as an alternative when using Ant, but I wasn’t going to re-write the company’s build process. So we had flex-mojos building our source and producing artifacts for deployment to our team’s Maven repository, but we needed to integrate our unit tests into our build. We were using dpuint and were excited to see that fluint had been released with Ant support. Currently flex-mojos doesn’t support Fluint, although my colleagues tell me they’re working on it, so I knew I was going to have to use Ant. To start I had to get flex-mojos building my test SWF so I could use the Fluint Ant task. The Ant support in Fluint requires that you produce a module SWF that will work with their test runner written in AIR. After an hour of messing with flex-mojos, I was unable to get the compile, or test-compile, goal to do what I wanted, so I decided to use the maven-ant-run plugin to compile our tests as well.

Below is the snippet I was able to get working to compile our tests and execute the Fluint test runner:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
<properties>
   <flex.home>PATH_TO_FLEX_SDK_HOME</flex.home>
   <fluint.testrunner>PATH_TO_FLUINT_AIR_RUNNER_EXECUTABLE</fluint.testrunner>
</properties>
...
<build>
   <plugins>
      <plugin>
         <groupId>info.flex-mojos</groupId>
         <artifactId>flex-compiler-mojo</artifactId>
         <version>2.0M9</version>
         <extensions>true</extensions>
         <configuration>
            <skipTests>true</skipTests>
         </configuration>
      </plugin>
      <plugin>
         <groupId>org.apache.maven.plugins</groupId>
         <artifactId>maven-antrun-plugin</artifactId>
         <executions>
            <execution>
               <id>fluint-test-compile</id>
               <phase>test-compile</phase>
               <configuration>
                  <tasks>
                     <!-- Pull in Flex Ant Tasks -->
                     <taskdef resource="flexTasks.tasks" />
 
                     <property name="FLEX_HOME" location="${flex.home}" />
 
                     <!-- Create test-classes directory -->
                     <mkdir dir="${project.build.testOutputDirectory}" />
 
                     <mxmlc file="${project.build.testSourceDirectory}/AirRunner.mxml" 
                        output="${project.build.testOutputDirectory}/AirRunner.swf" 
                        keep-generated-actionscript="false">
 
                        <load-config filename="${FLEX_HOME}/frameworks/flex-config.xml" />
                        <source-path path-element="${FLEX_HOME}/frameworks"  />
                        <compiler.library-path dir="${FLEX_HOME}/frameworks" append="true">
                           <include name="libs" />
                        </compiler.library-path>
                        <compiler.library-path dir="${project.build.directory}/.." append="true">
                           <include name="libs" />
                        </compiler.library-path>
                        <compiler.library-path dir="${project.build.directory}" append="true">
                           <include name="*.swc" />
                        </compiler.library-path>
                     </mxmlc>      
                  </tasks>
               </configuration>
               <goals>
                  <goal>run</goal>
               </goals>
            </execution>
            <execution>
               <id>fluint-test-run</id>
               <phase>test</phase>
               <configuration>
                  <tasks>
                     <!-- Pull in Fluint Ant Task -->
                     <taskdef name="fluint" classname="net.digitalprimates.ant.tasks.fluint.Fluint" />     
 
                     <property name="test.report.loc" location="${project.build.directory}/surefire-reports" />
 
                     <!-- Create reporting directory -->
                     <mkdir dir="${test.report.loc}" />
 
                     <fluint debug="true" 
                        headless="true"
                        testRunner="${fluint.testrunner}" 
                        outputDir="${test.report.loc}" 
                        workingDir="${project.build.testOutputDirectory}">
 
                        <fileset dir="${project.build.testOutputDirectory}">
                           <include name="**/AirRunner.swf"/>
                        </fileset>
                     </fluint>      
                  </tasks>
               </configuration>
               <goals>
                  <goal>run</goal>
               </goals>
            </execution>
         </executions>
         <dependencies>
            <dependency>
               <groupId>org.apache.ant</groupId>
               <artifactId>ant</artifactId>
               <version>1.7.0</version>
            </dependency>
            <dependency>
               <groupId>flex.ant</groupId>
               <artifactId>flexTasks</artifactId>
               <version>1.0.0</version>
            </dependency>
            <dependency>
               <groupId>net.digitalprimates</groupId>
               <artifactId>FluintAnt</artifactId>
               <version>1.0.1-SNAPSHOT</version>
            </dependency>
         </dependencies>
      </plugin>
   </plugins>
</build>

Couple of things to point out about the above snippet:

  • There are two dependencies on resources being available on the disk, the Flex SDK (flex.home property) and the Fluint Air Runner (fluint.testrunner property).
  • Using Ant I had to create the “test-classes” and “surefire-report” directory to stick with Maven conventions.
  • We adhered to the convention of naming our test runners for the Fluint Ant task “AirRunner.mxml” so we could use this snippet in a parent POM.
  • I had to change the dependency for the maven-ant-run plugin from Ant 1.6.5, which is the default, to Ant 1.7.0, which is required by the Fluint Ant task.

You may also notice that I’m using snapshot versions of the Fluint library and the Fluint Ant task. I ended up having to change the source of the Fluint library, Ant task, and AIR runner to get Fluint to work as I wanted it to with my build. Fluint is an awesome unit testing library, it just needed some tweaks. I made changes to fix the following:

  • The XML output from the Fluint AIR runner wasn’t compliant with what the Surefire Report plugin was expecting.
  • The name of output file from the Fluint AIR runner was in the convention “TEST-*.xml” which the SureFire reporting plugin expects.
  • Fluint had the notion of an error and failure being separate but it wasn’t implemented for the Flash or AIR test runners.
  • The Ant task didn’t allow the user to specify a working directory so that the AIR runner could be launched from the appropriate directory.

I later found out that AIR and relative paths don’t play nicely together (= at all, unless there is helper code), so we also had to re-factor our test suites to NOT rely on any assets unless they are embedded or referenced with absolute URIs. This made the change to the Fluint Ant task kinda worthless, but I kept it in anyway for when AIR works in the future. Additionally, it’s important to note, that the “headless” mode in the Fluint AIR runner is really just a minimized window that closes after the XML report is written; if you plan on running your CI build on an OS without a windowing solution, then FLuint will not work since AIR does not support running in a true headless mode. On a side note, my changes should address issues #5 and #22 on the Fluint Google Code site; issue #21 should be solved by the Ant dependency fix I spoke about above and issue #20 is just a matter of the fluintAnt15.jar being compiled with Java 1.6 instead of 1.5, I believe. I’ve submitted these fixes along with my code to the Fluint guys in an email, just haven’t heard anything back yet.

So at this point I had the build process working as I wanted such that I could run “mvn clean deploy site” and find a snapshot in our team’s maven repository and site documentation generated. On to CI. I have used CruiseControl many times in the past, but the idea of being entrenched in XML, especially with all the Maven and Ant fun, was discouraging so I decided to give Hudson a try this time around. Wow … Hudson is amazing improvement over CruiseControl. Completely UI driven, I have yet to find myself digging through XML and best of all. The post-build support feel a little lighter than CruiseControl’s, but I think that’s just because I haven’t come across an X10 plugin so we can get a stop light or glowing orb setup. Hudson provides trend reporting on builds and unit tests as well as embedded reporting for unit tests and xdoclet-like documentation; it also has tons of Groovy integration which I really like (not that we’re using it … yet). Initially I chose to go with the pure Maven build for our projects, but I then decided to switch back to the free-style build; I couldn’t get trend reporting for unit tests to work with the pure Maven build, so I think my conventions are off for the Fluint reporting. In the free-style build I set the “site” directory as the Javadoc location and the “surefire-report” directory as the test report directory. Even though there is more configuration in a free-style build, it was simpler in the short run to get what I wanted in Hudson running. If unit test trend reporting isn’t as important to your CI needs, then the pure maven build may be more along the lines of what you’d like to use so that you can get the additional build trigger “Build whenever a SNAPSHOT dependency is built”. On a side note, I’m working towards using the FlexCover support in flex-mojos to make our site reports complete, but haven’t had a chance to dive in yet.

I hope some of the hurdles I encountered can help if you’re trying to get your CI process working with Flex. The flex-mojos, Fluint, and Hudson guys have some good walkthroughs/tutorials to cover the details I left out. I’m always up for suggestions, so definitely feel free to rip into my solutions. :)

Mock objects and AS3 : Now I really don’t want to use explicit typing

Brian LeGros | October 25th, 2008 | programming  

So in my search for mock object libraries, I continue to run into frustration with explicit typing in ActionScript 3. I did some searching and found a really great mock object library called mock-as3. It’s an expectation based library, in its early stages, but surprisingly featured and intuitive. Here are some usage examples from the author.

I’ve been writing code in ActionScript using explicit types, like most everyone I know who uses AS3, so mock-as3 out of the box won’t meet my needs. If I wanted to begin using interface classes and stubbing out my mocks (as mentioned in the examples) I could, but I won’t; the author even comments that it is extremely tedious to do and doesn’t necessarily advocate it. He hopes to have features in future versions of the library available to handle this but for now they are not available. In general, implementing interfaces for all classes that I’d like to mock is something I don’t agree with in any language. I’m a believer that refactoring your code will make a use case for the use of a programmatic interface over time; there are explicit cases where they are useful, but in the case of mocking, I’m not a big fan.

In any case, I did some thinking and wondered if there was a way to convert an object to a different type at runtime. I figured it’d take some bytecode manipulation, but I’m new to the game, so others much have thought about this already I assumed. Sure enough, I found an implementation by Darron Schall called ObjectTranslator which will convert an object’s type at run-time. I ran through some basic examples and everything worked as expected, so I thought, why not try to convert Mock, which is the class used to mock an object, to the class type passed in at instantiation? The implementation of ObjectTranslator just switches a byte for the new class type and directly copies the bytes of the object into a new byte stream. Worth a shot right?

In mock-as3′s implementation Mock is a subclass of everyone’s favorite class, Proxy. I did a basic test creating an expectation with the same name as the method in my class I wanted to mock and then used ObjectTranslator to convert the mock’s type. I then passed the typed mock to something to consume it and test to see if my expectations return value was given. Below is a the code I wrote:

1
2
3
4
5
6
7
8
9
10
11
var mock : Mock = new Mock(new MyClass());
trace(describeType(mock));
 
mock.method("method1").returns("PASS!");
trace(mock.method1());
 
var newMock : MyClass = ObjectTranslator.objectToInstance(mock, MyClass);
trace(describeType(newMock));
 
var typedUsage : UsageClass = new UsageClass(newMock);
trace(typedUsage.method1() == "PASS!");

Everything works except the final call to trace() which shows false because the value being returned is “FAIL!”, which is the default value for the method in the class declaration. I thought, well maybe I can add functionality to Mock where on each call to method() or property() I will create a property on the mock with the same name of the property passed in and point it to callProperty or getProperty from Proxy. Mock is declared dynamic after all. I gave it a whirl but no luck, I’m guessing there is something special done with Proxy that when I used ObjectTranslator, didn’t come over. There were also some properties used by Mock that didn’t come over because they were not part of the new type, specifically expectations. Since mock-as3 uses its internal reference to expectations I was hoping I would get this for free, but it didn’t work out from what I can tell. Without a way to eval() the code necessary to create a method signature matching the existing signature in the class declaration, I’m pretty much stumped.

If anyone has any suggestions, I’m all for it, but I kinda threw up my hands and called it a day. The more I play with ActionScript 3, the more it feels like the Flex community is going to have to produce things equivalent to CGLib to do anything flexible with ActionScript3 that is still type-safe (e.g. – mocks, AOP, etc). It sounds like from a thread on FlexCoders that the community really wants a Proxy#newProxyInstance method, so hopefully this will make Proxy a little more useful. I’m not sure, however, if they want to be able to instantiate Proxy at run-time or be able to instantiate a formal target property from Proxy of the target’s type. I’m hoping for the latter, but I’m still new to AS3, so who knows. Back to stubs …

ActionScript: Just different enough to piss you off

Brian LeGros | October 19th, 2008 | programming  

So I’ve started my new job and I’m working with Flex and ActionScript 3. I was tasked with throwing together a couple classes and there respective unit tests this week. The classes don’t integrate with any external resources and mostly do pass through except for some cross cutting concerns (e.g. – logging, security, etc). I figured writing my tests would be pretty straight forward: throw together the appropriate test cases and in each mock out any dependencies.

Now when I think about a language I try to put it into the context of other languages I’ve had experience with, identify differences in language elements, and work from there. With respect to ActionScript, I tended to problem solve in the context of JavaScript since they are both based on ECMAScript, but I’ve run into some frustrations along the way.

To mock out an object in a test using JavaScript I’d typically write something like:

1
2
3
4
5
var dependency = new MyDependency();
dependency.methodToMock = function () { return true; };
 
var obj = new MyClass(dependency);
assertTrue(obj.passThroughMethodUsingMockThatICreated());

or if I wanted to mock out objects being instantiated by a dependency that I couldn’t inject:

1
2
3
4
MyDependency.prototype.methodToMock = function () { return true; };
 
var obj = new MyClass();
assertTrue(obj.passThroughMethodUsingMockThatIDidntCreate());

In ActionScript, assuming that MyDependecy is declared in an ActionScript class, the first and second approach I used in the above will not work. I did some reading on the Flex 3 livedocs and found out that the culprit was the traits object that was introduced in AS3. To abridge, the traits object is a copy of all applicable properties from parent classes and defined properties in the current class that need to be available at run-time to help reduce the performance hit of walking the prototype chain previously used for inheritance. The traits object is an internal mechanism which is not accessible by the developer. Prototype-base inheritance is still available, but falls secondary to traits. Awesome.

So unless I declare the methods of my class as members of the prototype for the class, I can’t manipulate them at run-time. So instead of the following:

1
2
3
4
5
public class MyDependency {
   public function methodToMock() : Boolean {
      ...
   }
}

I’d have to write:

1
2
3
4
5
public class MyDependency {
   prototype.methodToMock = function() : Boolean {
      ...
   }
}

So now I’ve got methodToMock available in a data structure I can mess with at run-time. I still, however, can’t accomplish what I did in JavaScript unless I add the keyword dynamic to the class declaration (as below) or remove the “strict” flag from the compiler:

1
2
3
4
5
public dynamic class MyDependency {
   prototype.methodToMock = function() : Boolean {
      ...
   }
}

Now I can manipulate the object and its class’ prototype the way I would in JavaScript. It irks me a bit that performance was the driving force for all of this hoopla, but I’m just an application developer, so I won’t pretend to understand all of the motivations for these decisions.

As another alternative, I thought about just using Object for all of my mocks, but I quickly dismissed the option since we’re using the explicit typing with ActionScript, as I suspect most are since its promoted for its performance boost. I also looked into using the Proxy class as a run-time solution, but alas it can’t be instantiated, only extended; this would mean writing class declarations for every mock I wanted to create, which seems kinda silly, and I still would have to deal with the explicit typing issue. On a side note, it would have been nice if Proxy had the option to be instantiated with the object it’s proxying as a constructor argument, mimic the type passed as the argument, and allow run-time manipulation. No idea if this is feasible though, so I’ll count it as a pipe dream for now. In any case, from my experience mocks are intended to be used within a context and disposable for the purpose of testing; why would I write anything more than inline code to utilize mock objects?

In the end, I’m probably going to be making end-to-end tests using stubs for the classes I want to test. Once we have some time to evaluate mock object libraries for ActionScript, I’ll probably start digging again for more answers. We’ll eventually need something to help us with expectation-based testing anyway, so a library will be the way to go. Hopefully I’ll end up finding something more like Mocha or Moq than JMock, although I think the opposite may be true.

There are language elements in ActionScript that I’m extremely grateful to have at my disposal (e.g. – events, properties, functions, etc). A few quirks exist though (e.g. – object/class manipulation at runtime and reflection) that still get me when I try to think about ActionScript in the context of JavaScript. Going forward I think I’m going to switch gears and solve problems more as I would a Java/C# developer than a JavaScript developer, favoring the use of libraries over the language features to get every day tasks done. I like ActionScript, but what good would a blog be if I couldn’t complain.

:)

NOTE: I can’t take credit for the tagline, some Flex developers I know have begun to adopt it and I borrowed it from Dan.