As the author of that mock framework Adam linked to I thought I should chip in with my thoughts on the issues that have been raised.
Regarding having to hand code the implementation of the class you want to mock I have found that with a couple of snippet templates for TextMate I can write them quite quickly. If you are going to hand-code stubs for use in testing without using a framework you are adding behaviour to a class which means you should then be testing that class too. To ease some of the pain until we can generate mock objects from interfaces I intend to bundle a bunch of support classes that provide mocks for many of the core flash class (think URLLoader, EventDispatcher, Socket, etc). Speak up if you've got suggestions for the classes you would like to see included initially. I have a couple of ideas about what we would need to be able to generate the mock classes: 1) Generate the .as for the mock from reflection information at runtime, then compile the generated .as at runtime with a self-hosted compiler (AS3 compiler in AS3) then load it via Loader.loadBytes and flash.utils.getDefinitionByName 2) Write an AS3 Parser in something like Java or Ruby that would provide access to the Abstract Syntax Tree from which we can generate the mock class, then compile the generated .as with mxmlc along with the test suite. By implementing a tool that provides the AST for an AS3 class we open up the doors for lots of fun like generating mocks, AOP, code mutation (think adding hooks for code coverage reporting, mutation testing, additional metadata directives) There is work in the Tamarin project for a self-hosted compiler however last I checked it wasn't far enough along for our purposes. The hxASM library looks interesting and could definately be an avenue worth exploring for this. Adam, I would be interested in collaborating on getting a port of hxASM to AS3 so that we can generate the necessary bytecodes to create mocks from an interface at runtime. cheers, Drew
