Re: [Asunit-users] ASUnit 101: Testing interface elements

[Luke B. <lb...@gm...>]

Hey David,

There are two questions here that seem related on the surface, but actually
are pretty different.

To the first question, "I am getting to the point where I am testing things
like the placement of
symbols on the stage, and the results of clicking on things like menu items.
What, if anything, is the best way to do unit tests on things like this?"

In general, we try to test more general functionality, like layout
algorithms, and the availability or existence of a particular symbol or
instance. We've found that testing an instances' position or size usually
leads to fragile tests that generate more work than they're worth. When a
designer wants to move something over by a pixel or two, suddenly you have
broken tests that need dealt with. So, to answer your question, I wouldn't
add those kinds of things to unit tests. Unit testing is definitely an
amazing tool, but it isn't a silver bullet. When building GUI applications
in ActionScript, it's still important to have some process for "functional
testing" or "acceptance testing" - basically - someone clicking around in
your application and making sure that things are in fact where they are
expected to be.

To the second question, "...what have you found is the best way to handle
symbols? The way I am doing it now is to create the symbols in my main app
FLA and set their linkage IDs, and then drag them into my test runner FLA as
I need them. Is there a cooler way to do this?"

I would strongly encourage you to avoid duplicating symbols across multiple
FLA files. Anytime a manual process is required to switch from test to
deploy (and back), there is a big risk of failure. We usually avoid using
Flash Authoring as much as possible. In cases where we are forced to use
Authoring, we try very hard to put absolutely zero code into the FLA file.
Symbols are defined with linkageIds, but no associated ActionScript. This
allows us to MTASC for real compilation, and the FLA file is simply a
library of assets. I have never actually used it, but I'm told that SWFmill
is an excellent tool that allows you to put regular image assets in a
directory and it will spit out a SWF file.

Basically, MTASC is a line command compiler that can be pointed at an
existing SWF file as input. It will take the referenced SWF and all
ActionScript found in the class path and combine them to a single output
swf. The ActionScript can access symbols by linkageId just as if you were
compiling from Flash. The great thing about this process, is that your
assets only exist in one place and MTASC can be used to deploy *and* to
test. Just give it different "main" file targets.

Both SWFmill and MTASC are free, open-source tools that can be found on
http://www.osflash.org along with some pretty good instructional material.

Ali and both use FDT <http://fdt.powerflasher.com> as a code editor and I
would posit that it is the strongest one available for ActionScript 2
development. It integrates nicely with MTASC btw.

Basically, if you have animated assets, go ahead and use Flash authoring to
create and compile them, but I highly recommend using MTASC to compile and
build your application.

Hope that helps,


Luke