On 2/6/12 6:22 PM, "Frédéric Thomas" <webdoubl...@hotmail.com> wrote:
> Michael,
>
> Thanks to clarify that point, it's very important to know that in the actual
> state, the framework is un-unit-testable (mainly for UIComponent(s) I guess,
> is that the same for the all framework ?).
>
I'm hoping Mike will quote his definition of a unit test. I suspect it is
from some standards body he told me about that I can't remember but I'm all
for shooting to meet its requirements. For sure, there is not enough
separation of concerns to allow substitution of dependencies of most of the
classes in the SDK.
Under the looser Wikipedia definition, the current mustella test suite (note
that I have not called it a unit testing framework on this mailing list) has
tests for the major classes in the framework. When you finally see the
code, there is a class called UnitTester that contains a set of tests. Mike
will probably rename that class shortly after I check it in :-)
The SDK code is the way it is because it started out in AS2 in a VM where
object creation was very expensive. We got our performance improvements by
having large monolithic classes. When we ported to AS3, we could not be
sure of its performance characteristics, so we did a straight port and kept
those large classes. AS3 was much faster, but as I said, in my attempt to
do a major refactoring, there was a performance hit for small apps, and with
mobile being a important target, we opted not to pursue a refactoring.
I'm not a big fan of doing things to the byte code such that you lose the
ability to map the code back to the source code, but I still believe we can
make the right trade-offs and get a better framework. I am still planning
on giving up on strict backward compatibility and starting over.
Refactoring is hard, and trying to synchronize it with what I hope will be
tons of changes going forward will be very difficult.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
