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