cookies and code

I’ve pushed out a couple new features and a bug fix for the flexRpcStubs project. Release 0.3 of the library is available for download on github. In terms of features, you can now filter HTTP calls by HTTP method as well as parameters and HTTP headers. Arguments provided to the result/fault method of HTTPServiceStub and RemoteObjectStub can now be of type literal, Class, Date, RegExp, or Hamcrest matcher rather than just literals and Hamcrest matchers; thanks to Drew for letting me steal the idea from Mockolate, my new favorite mock object framework for AS3. I also fixed a bug in RemoteObjectStub which was not dispatching events on the RemoteOperationStub; thanks to ropp for the fix.

If anyone has SDK classes they’d like to see stubs for, please let me know. I’ve been sent a draft of a ModuleLoaderStub and have a couple ideas for handling SWFLoader, so keep an eye out for more updates as I find time.

I burned the midnight oil tonight and was able to get release 0.2 of the flexRpcStubs project out on Github. In this release I’ve added the ability to add a rootCause to a fault on RemoteObjectStub, the ability to match parameters and headers on HTTPServiceStub, and the ability to use hamcrest-as3 matchers along with literals for both HTTPServiceStub and RemoteObjectStub. Additionally, I’ve thrown up some concise examples which, I hope, will help to show simple use cases using stubs in your unit tests. Here are links to the examples for HTTPServiceStub and RemoteObjectStub, just in case you don’t want to dig in. As always I look forward to feedback on the project. If you don’t want to build it yourself, I’ve thrown out a SWC for download on GitHub as well.

A short note. For simplicities sake, I’ve created a project on GitHub (http://github.com/blegros/flexRpcStubs) to house the mx.rpc stubs which help with testing Flex service classes. The HTTPServiceStub and RemoteObjectStub classes have had a couple of bugs fixes and I’ve added build script to generate a SWC for simplicity. You can read more about the stubs in my initial posting; I hope to update the project soon with some practical usage examples.

If you have any suggestions for changes, feel free to fork and pass a pull request my way. Hope this helps those who asked for a bit more structure.

This past weekend, I finished my port of the Hudson Xvnc plugin to the FlexUnit Ant task. I’m hoping this will help those who don’t have access to the plugin, or dont’ use Hudson, but want to execute headless builds using FlexUnit and Xvnc. In addition to this work, I’ve added a few wiki pages to the newly launched FlexUnit.org’s wiki instance. A break down of the all the features available in the FlexUnit Ant task can be found @ http://docs.flexunit.org/index.php?title=Ant_Task. Additionally, to see the Ant task in action in a few variations, check out the FlexUnit4SampleCIProject on Github; I also show a basic POM using Flexmojos and FlexUnit4. For a general culmination of FlexUnit and continuous integration experience for running headless builds, check out http://docs.flexunit.org/index.php?title=Continuous_Integration_Support. Hopefully this information can help to prevent some people from experiencing the painstaking lessons I had to go through.

Next I’m off to update the FlexUnit 4 CI builds to work with versioning as well as integrate the new FlexPMD (CPD, Metrics) to get some more sexy Hudson reporting going on. If you’re interested in seeing the latest rendition of our CI process, check out http://flexunit.digitalprimates.net.

Over the last year or so, I’ve worked to integrate xvfb into the projects I work with at the office and in the community to allow the execution of truly headless builds for Flex-based applications. Since the Flash Player and AIR require a windowing environment and typically unit and integration tests require this environment to be executed, integrating Flex into a CI process on Linux gets pretty hairy without having X-Windows support. Recently I’ve found myself switching from xvfb to Xvnc to more easily support headless builds in Flex. VNC server packages are pretty ubiquitous for most Linux distros, so getting something installed is pretty simple. What took me a couple of steps was getting setup based on the configuration of my CI server. In an effort to make searching a little simpler, here are the steps for using the Xvnc-plugin with Hudson on Ubuntu Desktop 8.10 with the default Tomcat 6 installation:

1. Install the vnc4server package (i.e. – “apt-get install vnc4server”).
2. Assuming the Ubuntu installation came with Tomcat 6 and is setup to run as the tomcat6 system user, do the following:
1. Execute vncpassword as any user, following the prompts to set a password to be used by the “vncserver” command. This will create the “~/.vnc/password” file needed to run the vncserver command.
2. Copy the file at ~/.vnc/password to /usr/shared/tomcat6/.vnc/password which is the default home directory for the tomcat6 user on the standard install of Ubuntu Desktop.
3. Change the ownership rights on the “password” file to be owned and created by the “tomcat6″ user (i.e. – chown tomcat6:tomcat6 /usr/shared/.vnc/password)
4. Edit /etc/init.d/tomcat6, adding a line to set the HOME environment variable to “/usr/shared/tomcat6″ (i.e. – export HOME=/usr/shared/tomcat6). Since “tomcat6″ is setup as a system user, from what I can tell, this environment variable is not set by default when a process is running as this user. The “vncserver” command will need this variable to determine where the “password” file is located to launch its process.
3. If Tomcat is running as a standard user, execute the “vncserver” command using any display number (e.g. – vncserver :99) as the user. The command will force a prompt to enter a password to use for the server which will create the “~/.vnc/password” file with the appropriate ownership rights in the appropriate home directory.
4. In Hudson, install the Xvnc-plugin for Hudson (http://wiki.hudson-ci.org/display/HUDSON/Xvnc+Plugin)
5. OPTIONAL: In Hudson, under “Manage Hudson” -> “Configure system” -> “Xvnc”, set the “Base display number” field to 99. This is the base display number xvfb-run uses and I’m partial to reusing this setting.
6. Under the configuration for you CI build, check the box labeled Run Xvnc during build.
7. If all goes as expected, then your build should kick off the “vncserver :99″ command, set the DISPLAY environment variable to 99, execute your build to completion, and then execute “vncserver -kill :99″ to kill the Xvnc process.

Based on these steps, I’m am currently building Xvnc support into the FlexUnit4 Ant task for those who don’t use Hudson and can’t take advantage of the Xvnc-plugin. The Xvnc support is a basic mirror of what the plugin for Hudson aims to provide. Hopefully someone will find this footwork useful and save some time. I’m by no means a Linux guru, so if anyone has more insight, please feel free to share so others can benefit from your knowledge as well.

Happy building!

UPDATE: I’ve now tested and deployed the Xvnc support for the FlexUnit Ant task. Hopefully this will help anyone who’s not using Hudson but wants to take advantage of headless FlexUnit test executions using Xvnc.

I will be presenting on Flex, Rails, and RubyAMF with Jake Swanner at the September 10th Adogo meeting. What’s great about this meeting this month, is that we’re pairing up with the ORUG and having a joint meeting, so this audience will hopefully be a good mix of Ruby and Flex developers. Jake’s been busting ass on the Rails side of things, so I think the presentation is gonna go great. If you’re in town on that Thursday and feel like taking in some Ruby and Flex love, stop by Devry at Millenia at 7:00 PM, Room 114. We will also be using Connect to broadcast the presentation, so if you’re interested in attending remotely, just let me know and I’ll try to get you a couple URLs for the meeting. I’m sure, as is our usual pre-Adogo tradition, we will be meeting at BJ’s Brewhouse for beers around 6:00 PM. Hope you can make it out.

Well I gave my hastely assembled and zero practiced version of a FlexUnit4 and mock-as3 presentation last night at the Adogo and I only caught a few people snoozing, so that is a +1 in my book. Unit testing can be extremely dry for most people, but building tools to make me more productive always holds my interest so that’s how I’ll explain my enthusiasm. Thanks to Drew Bourne and Michael Labriola for the help with the presentation. I blubbered through most of the points on their APIs and definitely mispoke on a few instances, but as long as the recording doesn’t get too much traffic we should be fine. Thanks as well to Russ, Vincent, Brian, and Greg for keeping me company after the meeting over a few beers while I waited for my wife’s flight to get in.

I’ve published the source and recording for anyone who is interested.

The early bird price (~$35) for registration to FlashCamp Orlando 2009 has been extended until May 15, 2009! Let’s face it, in this economy, every little bit helps. If you weren’t able to make it out to 360|Flex or cf.objective this year, or you can spare a Friday out of the office, come out to support a local developer event sponsored by Adobe and Universal Mind. Lunch, parking, door prizes, great sessions, and lots of great networking opportunities come with the registration price. The best part of it all is at the end of the day, you can drive home instead of staying in a dank motel like you do with most events. Tampa and Melbourne are still what I consider within driving distance, but you may still elect for the motel/hotel.

If you haven’t seen it yet, an interview has been posted with Adogo’s very own Jason Madsen about his session at FlashCamp. Hope you can make it out!

A little belated, but registration for FlashCamp Orlando 2009 opened this weekend with early bird expiring on May 1st at $35. Fear not though, the standard registration price is a mere ~$50 which, IMO, is a significantly small fee to attend a one day event.

FlashCamp (formerly FlexCamp) is a one-event day sponsored by Universal Mind and Adobe in which developers and designers can take a deep dive into topics ranging from introductory to advanced from the Flex world. This year Adogo’s very own Maxim Porges and Jason Madsen will be presenting along side Greg Wilson, of Adobe, as well as David Tucker, Andrew Powell, and Christian Saylor, of Universal Mind, and Carl Smith from nGenWorks. The event will take place on May 29th from 8:30 AM to 5:30 PM. Registration includes free parking, lunch, door prizes and lots of great networking.

If you have the time available, I definitely suggest signing up for a spot, availability is limited. I won’t be able to attend, or speak at, the event since we’ll be welcoming our 1st child into the world this month, but I would definitely be there otherwise. Hope you can make it out!

Mike Labriola today announced on the Fluint Discussion group the big news a few in the Fluint team have been sitting for months now. The Fluint team is leading an OSS initiative to create the next version of the FlexUnit product. What’s great about this initiative (as Mike outlines on the mailing list) is that the new version of Fluint has been designed to mimic a lot of the conventions found in JUnit 4 while still addressing all of the problems Fluint solves for us in the Flex world. I know, for me, this means being more productive when writing tests and finally having better tooling when working with Flex. Here are some of the features listed from Mike’s email:

• Metadata based Test and Suite identification (no more need to extend testcase or testsuite)
• Hamcrest matchers courtesy of the hamcrest-as3 project.
• Theories, DataPoints and Assumptions
• Ignorable tests
• Enhanced Sorting and Filtering
• Custom runner integration

Probably one of the coolest part of this entire framework thus far is that last item. The Fluint team has already been able to successfully run legacy unit tests from the current versions of FlexUnit and Fluint. This means that you can have hybrid suites of tests in the new FlexUnit (e.g. -FlexUnit, Fluint, FUnit, asunit, etc) making migration between frameworks relatively simple.

We’re going to be launching a public alpha release in the near future, but we are still continuing work on Fluint at least as far as release 1.2 (1.1.1 was release yesterday). Please keep in mind however, the goal is for FlexUnit to become what would have been Fluint 2.0. Look for more details in the coming weeks.

Here’s to better testing!