Re: [Asunit-users] Help. Having problems compiling swf using ASUnit and AS3.

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

Hey Robert,

Answers inline below:

I got a response from the asunit-users mailer daemon saying that my
> registration on the list had been confirmed, so I don't know why you are
> having to approve emails from me.  If I missed a step somewhere. please let
> me know.


It seems the "moderate" bit was turned on automatically, I got it sorted
out, thanks for letting me know and sorry for the confusion.

I appreciate you efforts on this project obviously, but I think that
> auto-creating test-suites for every class is not necessarily the best way of
> going about things.  I come from a .NET shop and in NUnit you give a class
> an attribute to define that it is a TestFixture.  So when NUnit runs, it can
> pick up all of your tests and execute them.  JUnit does something similar I
> am pretty sure.

I am not terribly certain as to whether or not something like what I've
> mentioned above is even possible in ActionScript, but I would rather create
> TestCases by hand and call them by hand then to have them auto-generated for
> me.


There is definitely nothing stopping you from creating test cases and test
suites by hand.  The tools that we have provided are completely platform and
tool agnostic and as such don't preclude anyone from using Eclipse, Flash
Develop or any other tools for that matter. We happen to use FDT (an eclipse
plugin) when we're doing AS2 work and Flex Builder (another Eclipse plugin)
when we're doing AS3/MXML work. We used to use Flash Authoring and TextPad.
We also have a surprising number of users that use the Flash Authoring tool,
so we have to make sure that the features we release are compatible with an
exceedingly wide variety of development environments and work flows. This
means that we can't take advantage of some of the features that NUnit and
JUnit can - because we aren't sure about which compiler you're using. Thanks
to limitations of the Flash Player and the varying compilers that one may
use, we also can't just "pick up all your tests and execute them". You have
to manually reference them from some class that is referenced by your 'main'
class. This is why we use code-generation, which I agree isn't the ideal
choice.

I just re-read your message, and now I am not sure what you are saying.  Are
> you saying that both TestCases and TestSuites are created/maintained
> automagically, or are you saying that a test suite is modifed each time you
> add a test case to a project?  The second is good the first is not.  I don't
> want to have a TestCase in my directory structure unless I put it there.


Sorry for the confusion. I work pretty hard to avoid performing mundane,
repetitive tasks. I like to spend my time solving problems, not necessarily
re-writing class definitions and setup methods - essentially scaffolding for
running code. It is for this reason, that we created a small handful of
tools that will spit out a new class definition and a new test case if you
hand them a fully qualified class name. This is similarly handled for JUnit
in Eclipse, but since we can't rely on the fact that people are using
Eclipse, we built these features into:

A Flash Authoring JSFL Extension
A Cross-Platform XUL desktop application
AsProject, a Cross-Platform ruby/shell application

These utilities don't actually write any of your application code (they
aren't modeling tools), and the don't do round-trip code-modification or
anything fancy like that... They just create some folders and a new class
and a new test case when you give them a full name and a class path to work
with. You have to fill them in.

After manually managing our Test Suites for a short time, Ali and I realized
that this was a perfect business case for automation. Our development
process when creating new features, is to create a new class, a new test
case and then run only that new test case while adding functionality to the
new class. Afterward, we compile the entire test suite - including every
single defined test case. Manually managing the process of test inclusion
turned out (for us) to be a pretty error-prone task. I'm sure there are
other developers out there that are detail-oriented enough to manage this
100% of the time. For us, we found that a few test cases would find their
way into the application that weren't getting included in any of our suites,
and later on, low and behold, those test cases were failing, but no one was
getting notified. It is for this reason, that we added test suite automation
to the aforementioned tools. Admittedly, we are forced to think of test
suites slightly differently than the Java and .NET crowds seem to. We tend
to let our test suites simply get generated and trust them to point at any
and all files in our test directory that end with * Test.as<http://test.as/>.
This way we can just tell our TestRunner something like:

start(AllTests);

and we know that every single test case will be executed. No room for human
error.

Of course all of our tools that automate test suite creation give you the
option to turn that feature off (To be accurate, you actually have to be
explicit when you want it done).

I've recently spent a good deal of time getting FlashDevelop up and
> running.  I'd rather not go through that again with ASProject right now.  I
> like using the best tool available, but I've barely heard anything about
> ASProject, so I don't think I'll be switching just yet.   I am also pretty
> sure that there are alot of Eclipse users out there who would like to use
> your unit testing library that don't want to give up using Eclipse to do
> it.  I think that you should consider that most people using a unit testing
> framework are probably fairly sophisticated users to begin with, so you
> should expect them to need some kind of tool to create tests for them.  I
> write NUnit tests by hand, so surely I can write ASUnit tests by hand, and
> if I can't, maybe that should give you pause.


As I mentioned before, we are keenly aware of the wide variance in tool
choices for our users and it is for this reason that we make absolutely no
assumptions about what environment they are working in. We have been using
the XUL UI and more recently, AsProject while working with Eclipse and found
that they work just fine side by side. I definitely understand your
hesitation with getting into AsProject and I think it's newness is probably
the strongest argument against it. The XUL UI though, is a powerful tool
that has been out for quite some time and shouldn't take more than 5 or 10
minutes to get up and running. The main thing that these tools help with
though is showing users instantly how ActionScript unit testing differs from
other environments (like JUnit and NUnit) that they may be more familiar
with.

You mention that people unit testing "are probably fairly sophisticated
users" and it's funny that you brought it up because that is precisely what
I assumed as well!

As it turns out, there are a stunning number of ActionScript developers out
there that never even heard of unit testing before working with AsUnit, some
of whom we probably haven't supported as much as I would have liked, but
others have gotten test infected coming in from a design background. I try
(sometimes unsuccessfully) to support these folks more than the
sophisticated developer because I think they are why Flash has become the
success that it is. With that said, I hope we're not actually alienating
either group, but I suspect that there are far more new-to-unit testing
ActionScripters than test-infected gurus.

I hope this explanation helps.


Thanks,

Luke Bayes
www.asunit.org