In the beginning, I had the idea of adding enums to AS3. The way I’d do it was by using a simple utility that could process an enum declaration file and turn it into an AS3 class that provides enum-like behaviour (iterate over the values, no new values allowed at run time etc.) I created a basic version of this, but ran into the problem of how to run an AS3-based application via the command line. AIR is no good for this: running an AIR application via the command line results in the process forking and the command line process ending, whilst the AIR process carries on. So if the process ran via Ant for example, there would be no way of knowing if the process succeeded or failed. The project therefore was shelved until I found a solution to this.
This year, I heard about redtamarin. At last I had a way of running ActionScript from the command line, which – rather than leading to a nice command line tool – led me to shave a yak:
- As I started writing the file read/ writing code and the like, it occurred to me that I ought to write some automatic tests for that that code.
- Those tests could just have been basic integration tests involving reading pre-written files, generating AS3 files from that and testing the results. I figured it would be far better though to mock the functionality of the redtamarin built-in classes and run the tests via FlexUnit.
- I started looking at those built-in classes. I’m a classic “lazy developer” who’ll spend a day writing a script to automate a repetitive data entry task that would take an hour to do manually. So I decided that, rather than just quickly knock up some mock classes, I’d write a utility that used the describeType function to analyse those classes and generate the mock classes automatically.
- It quickly became apparent that describeType wasn’t up to the job. I needed a better way of extracting out the information I needed. I discovered that the AS3Commons library was up to the task however. So I started investigating using that.
- AS3Commons was ideal. However, I figured that rather than just write the utility for generating mock classes, I’d write an advanced version of describeType first, which I could use to learn my way around the AS3Commons data structures. And so AS3Introspection was born.
- So now I have AS3Introspection, I can use that as the starting point for my mocking utility. I can then generate a mock of redtamarin classes and then write my unit tests for the AS3 Enums utility and get that finally written.
My yak is well and truly shaved and I’m now on the my way back to sanity. I could have done things so much more sensibly though:
- Create some basic code for the AS3 Enums utility, then
- Create some test files and use the utility to create the output, then
- Use that to create a basic test framework. Then
- Create a simple mock class containing just those methods that I use to enable testing via FlexUnit.
- With AS3 Enums tested, release it, then finally start thinking about using AS3Commons to create an automated system.
By replacing my recursive workflow that I have followed with a simple iterative one, I could have released the AS3 Enums utility already and I could be unit testing it already. Rather than burying myself beneath a mountain of things that need completing before I can finally get back to the original task, I could have gradually implemented each idea in turn before moving on. Both methods achieve the same things at the end. Yak shaving just means I’ll end up release much of it in the reverse order to what I wanted to release it.
I live and learn. Hopefully next time I start heading down the yak shaving path, I’ll notice more quickly and will avoid repeating my mistake. 🙂
If you are wondering where the shaved yak image comes from by the way, it’s an action figure of the Ren and Stimpy character: The Shaven Yak.