asunit-users

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

[Robert S. <rob...@gm...>]

Has anyone else had this problem?

C:\SVN\AgCg\ActionScript3\Projects\ASUnitDemo\tests\ExampleTest.as(4): col:
35 Error: The definition of base class TestCase was not found.

I am using FlashDevelop and Ant, but I know neither is my problem as I tried
to compile by hand:

C:\SVN\AgCg\ActionScript3\Projects\ASUnitDemo>mxmlc -sp="C:/Program
Files/AsUnit/framework/as3/asunit"
-sp=C:/SVN/AgCg/ActionScript3/Projects/ASUnitDemo/tests
-default-frame-rate=24 -default-background-color=0xFFFFFF -default-size 550
400 -o=C:/SVN/AgCg/ActionScript3/Projects/ASUnitDemo/deploy/App.swf --
C:/SVN/AgCg/ActionScript3/Projects/ASUnitDemo/src/App.as

My directory structure is as follows:

ASUnitDemo/
-src/
--App.as
--Example.as
-tests/
--AllTests.as
--ExampleTest.as

The contents of the relevant files are as follows:

App.as
package
{
    import flash.display.Sprite;
    import flash.display.StageAlign;
    import flash.display.StageScaleMode;
    import ExampleTest;

    public class App extends Sprite
    {
        public function App()
        {
            init();
        }

        private function init():void
        {
            stage.scaleMode = StageScaleMode.NO_SCALE;
            stage.align=StageAlign.TOP_LEFT;
            var tests:ExampleTest = new ExampleTest();
        }
    }
}

Example.as
package  {

    public class Example {

        public function Example() {
        }
    }
}

AllTests.as
package {
    import asunit.framework.TestSuite;
    import ExampleTest;

    public class AllTests extends asunit.framework.TestSuite{

        public function AllTests() {
            addTest(new ExampleTest());
        }
    }
}

ExampleTest.as
package  {
    import asunit.framework.TestCase;

    public class ExampleTest extends TestCase {
        private var instance:Example;

        public function ExampleTest(testMethod:String = null) {
            super(testMethod);
        }

        protected override function setUp():void {
            instance = new Example();
        }

        protected override function tearDown():void {
            instance = null;
        }

        public function testInstantiated():void {
            assertTrue("Example instantiated", instance is Example);
        }

        public function test():void {
            assertTrue("failing test", false);
        }
    }
}

Thanks in advance for any help!

Robert

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

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

I'm not sure why you're getting that particular error, but you should be
running your test cases from a TestRunner, not just instantiating them
directly.

Essentially, you want two application roots, one that is your deployed
application, and the other that extends asunit.textui.TestRunner and calls:

start(TestCaseOrTestSuite:Class, [methodName:String, traceOutput:Boolean]);

Then you want MXMLC to switch between the the deployed application root or
your concrete TestRunner depending on what you're doing at the moment.

You should know that if you pass a methodName to the start method, the base
TestCase will call setUp, then the method and stop. This gives you the
ability to attach visual assets to the stage (using
TestCase.addChild(child:DisplayObject)),
and actually see them...


Please let us know if that doesn't solve the problem.


Thanks,


Luke Bayes
www.asunit.org

On 3/31/07, Robert Stackhouse <rob...@gm...> wrote:
>
> Has anyone else had this problem?
>
> C:\SVN\AgCg\ActionScript3\Projects\ASUnitDemo\tests\ExampleTest.as(4):
> col: 35 Error: The definition of base class TestCase was not found.
>
> I am using FlashDevelop and Ant, but I know neither is my problem as I
> tried to compile by hand:
>
> C:\SVN\AgCg\ActionScript3\Projects\ASUnitDemo>mxmlc -sp="C:/Program
> Files/AsUnit/framework/as3/asunit"
> -sp=C:/SVN/AgCg/ActionScript3/Projects/ASUnitDemo/tests
> -default-frame-rate=24 -default-background-color=0xFFFFFF -default-size
> 550 400 -o=C:/SVN/AgCg/ActionScript3/Projects/ASUnitDemo/deploy/App.swf --
> C:/SVN/AgCg/ActionScript3/Projects/ASUnitDemo/src/App.as
>
> My directory structure is as follows:
>
> ASUnitDemo/
> -src/
> --App.as
> --Example.as
> -tests/
> --AllTests.as
> --ExampleTest.as
>
> The contents of the relevant files are as follows:
>
> App.as
> package
> {
>     import flash.display.Sprite;
>     import flash.display.StageAlign;
>     import flash.display.StageScaleMode;
>     import ExampleTest;
>
>     public class App extends Sprite
>     {
>         public function App()
>         {
>             init();
>         }
>
>         private function init():void
>         {
>             stage.scaleMode = StageScaleMode.NO_SCALE;
>             stage.align=StageAlign.TOP_LEFT;
>             var tests:ExampleTest = new ExampleTest();
>         }
>     }
> }
>
> Example.as
> package  {
>
>     public class Example {
>
>         public function Example() {
>         }
>     }
> }
>
> AllTests.as
> package {
>     import asunit.framework.TestSuite;
>     import ExampleTest;
>
>     public class AllTests extends asunit.framework.TestSuite{
>
>         public function AllTests() {
>             addTest(new ExampleTest());
>         }
>     }
> }
>
> ExampleTest.as
> package  {
>     import asunit.framework.TestCase;
>
>     public class ExampleTest extends TestCase {
>         private var instance:Example;
>
>         public function ExampleTest(testMethod:String = null) {
>             super(testMethod);
>         }
>
>         protected override function setUp():void {
>             instance = new Example();
>         }
>
>         protected override function tearDown():void {
>             instance = null;
>         }
>
>         public function testInstantiated():void {
>             assertTrue("Example instantiated", instance is Example);
>         }
>
>         public function test():void {
>             assertTrue("failing test", false);
>         }
>     }
> }
>
> Thanks in advance for any help!
>
> Robert
>
>
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
> your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Asunit-users mailing list
> Asu...@li...
> https://lists.sourceforge.net/lists/listinfo/asunit-users
>
>

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

[Robert S. <rob...@gm...>]

Thanks for the response.  I found the yahoo example in the comm folder of
the AsUnit repository, and figured it out from there.  Is there currently a
way to keep from having to explictly reference all the test methods as in
NUnit or JUnit?  Though that probably uses reflection, and I am not sure AS3
supports anything like that or not.

I will try to post a tutorial on how to use AsUnit with AS3 sometime soon.
I will CC this list so y'all can correct me if I'm wrong about something.

As far as usage goes, I am planning to simply have two projects, one that
uses my library and another that tests it.  Speaking of testing, are y'all
aware of anything that will let you do functional testing on Flash Apps.
That would be a huge selling point with my boss.

I am uncertain as how to use the TestSuite class. Does that work like test
suites in JSUnit were you can just load multiple runners and have them
execute at once?  If so, could someone point me to an example?

Thanks again for your help,

Robert


On 4/6/07, Luke Bayes <lb...@gm...> wrote:
>
> I'm not sure why you're getting that particular error, but you should be
> running your test cases from a TestRunner, not just instantiating them
> directly.
>
> Essentially, you want two application roots, one that is your deployed
> application, and the other that extends asunit.textui.TestRunner and
> calls:
>
> start(TestCaseOrTestSuite:Class, [methodName:String,
> traceOutput:Boolean]);
>
> Then you want MXMLC to switch between the the deployed application root or
> your concrete TestRunner depending on what you're doing at the moment.
>
> You should know that if you pass a methodName to the start method, the
> base TestCase will call setUp, then the method and stop. This gives you the
> ability to attach visual assets to the stage (using TestCase.addChild(child:DisplayObject)), and actually see them...
>
>
> Please let us know if that doesn't solve the problem.
>
>
> Thanks,
>
>
> Luke Bayes
> www.asunit.org
>
>  On 3/31/07, Robert Stackhouse <rob...@gm...> wrote:
>
> > Has anyone else had this problem?
> >
> > C:\SVN\AgCg\ActionScript3\Projects\ASUnitDemo\tests\ExampleTest.as(4):
> > col: 35 Error: The definition of base class TestCase was not found.
> >
> > I am using FlashDevelop and Ant, but I know neither is my problem as I
> > tried to compile by hand:
> >
> > C:\SVN\AgCg\ActionScript3\Projects\ASUnitDemo>mxmlc -sp="C:/Program
> > Files/AsUnit/framework/as3/asunit"
> > -sp=C:/SVN/AgCg/ActionScript3/Projects/ASUnitDemo/tests
> > -default-frame-rate=24 -default-background-color=0xFFFFFF -default-size
> > 550 400 -o=C:/SVN/AgCg/ActionScript3/Projects/ASUnitDemo/deploy/App.swf --
> > C:/SVN/AgCg/ActionScript3/Projects/ASUnitDemo/src/App.as
> >
> > My directory structure is as follows:
> >
> > ASUnitDemo/
> > -src/
> > --App.as <http://app.as/>
> > -- Example.as <http://example.as/>
> > -tests/
> > --AllTests.as
> > --ExampleTest.as
> >
> > The contents of the relevant files are as follows:
> >
> > App.as <http://app.as/>
> > package
> > {
> >     import flash.display.Sprite;
> >     import flash.display.StageAlign;
> >     import flash.display.StageScaleMode;
> >     import ExampleTest;
> >
> >     public class App extends Sprite
> >     {
> >         public function App()
> >         {
> >             init();
> >         }
> >
> >         private function init():void
> >         {
> >             stage.scaleMode = StageScaleMode.NO_SCALE;
> >             stage.align=StageAlign.TOP_LEFT;
> >             var tests:ExampleTest = new ExampleTest();
> >         }
> >     }
> > }
> >
> > Example.as <http://example.as/>
> > package  {
> >
> >     public class Example {
> >
> >         public function Example() {
> >         }
> >     }
> > }
> >
> > AllTests.as
> > package {
> >     import asunit.framework.TestSuite;
> >     import ExampleTest;
> >
> >     public class AllTests extends asunit.framework.TestSuite{
> >
> >         public function AllTests() {
> >             addTest(new ExampleTest());
> >         }
> >     }
> > }
> >
> > ExampleTest.as
> > package  {
> >     import asunit.framework.TestCase;
> >
> >     public class ExampleTest extends TestCase {
> >         private var instance:Example;
> >
> >         public function ExampleTest(testMethod:String = null) {
> >             super(testMethod);
> >         }
> >
> >         protected override function setUp():void {
> >             instance = new Example();
> >         }
> >
> >         protected override function tearDown():void {
> >             instance = null;
> >         }
> >
> >         public function testInstantiated():void {
> >             assertTrue("Example instantiated", instance is Example);
> >         }
> >
> >         public function test():void {
> >             assertTrue("failing test", false);
> >         }
> >     }
> > }
> >
> > Thanks in advance for any help!
> >
> > Robert
> >
> >
> >
> >
> >
> > -------------------------------------------------------------------------
> > Take Surveys. Earn Cash. Influence the Future of IT
> > Join SourceForge.net's Techsay panel and you'll get the chance to share
> > your
> > opinions on IT & business topics through brief surveys-and earn cash
> >
> > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> > _______________________________________________
> > Asunit-users mailing list
> > Asu...@li...
> > https://lists.sourceforge.net/lists/listinfo/asunit-users
> >
> >
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
> your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Asunit-users mailing list
> Asu...@li...
> https://lists.sourceforge.net/lists/listinfo/asunit-users
>
>

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

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

Hey Robert,

Thanks for taking the time to write this up, we should definitely talk more
before you get too far.

First off, please join the asunit-users list as I have to manually approve
emails from non-members and it causes a delay for your message to get out.

Second - there are a small handful of tools available to help you build
classes, test cases and test suites (The AsUnit MXP, AsUnit XUL
Ui<http://www.asunit.org/#getStarted>,
and AsProject <http://code.google.com/p/asproject/>). The XUL UI, will let
you configure your project however you want, but it has the drawback that it
has to be kept in sync with your Flex Builder project manually. The MXP and
AsProject tools expect your test cases to be in the same project space as
your source classes. This doesn't mean  that your test source gets compiled
into your deployed application as the dependency checker in the compiler
should only find references to test features when compiling the Test Runner,
and not when compiling the main application.  A single flex 2 project can
have many application roots, each of which will spit out a separate SWF file
based on what classes are referenced from that root.

Please take a look at AsProject <http://code.google.com/p/asproject/> to get
some idea as to how we structure applications these days. We're actively
building tools that support this project layout and hoping that the
community will agree that it makes sense. If you choose to layout a project
differently, you will probably not be able to take advantage of these
features as they become available.

Regarding your question of test suites, you can think of each ActionScript
test suite as a Composite
<http://c2.com/cgi/wiki?CompositePattern>structure that contains any
number of TestCases and other TestSuites. Each
of the aforementioned tools will automate construction of test suites so
that you can be assured that all of your tests are being executed. The only
time I manually interact with these files is when debugging some feature or
set of features, otherwise I usually just edit the Test Runner's start call
to execute the test case that I'm currently interested in, and then edit it
back to running AllTests before I check in.

Hope that helps!

Please keep the questions coming, I'm certain you're not the only one.


Luke Bayes
www.asunit.org

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

[Robert S. <rob...@gm...>]

Luke,

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.

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.

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.

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.

Robert

On 4/9/07, Luke Bayes <lb...@gm...> wrote:
>
> Hey Robert,
>
> Thanks for taking the time to write this up, we should definitely talk
> more before you get too far.
>
> First off, please join the asunit-users list as I have to manually approve
> emails from non-members and it causes a delay for your message to get out.
>
> Second - there are a small handful of tools available to help you build
> classes, test cases and test suites (The AsUnit MXP, AsUnit XUL Ui<http://www.asunit.org/#getStarted>,
> and AsProject <http://code.google.com/p/asproject/>). The XUL UI, will let
> you configure your project however you want, but it has the drawback that it
> has to be kept in sync with your Flex Builder project manually. The MXP and
> AsProject tools expect your test cases to be in the same project space as
> your source classes. This doesn't mean  that your test source gets compiled
> into your deployed application as the dependency checker in the compiler
> should only find references to test features when compiling the Test Runner,
> and not when compiling the main application.  A single flex 2 project can
> have many application roots, each of which will spit out a separate SWF file
> based on what classes are referenced from that root.
>
> Please take a look at AsProject <http://code.google.com/p/asproject/> to
> get some idea as to how we structure applications these days. We're actively
> building tools that support this project layout and hoping that the
> community will agree that it makes sense. If you choose to layout a project
> differently, you will probably not be able to take advantage of these
> features as they become available.
>
> Regarding your question of test suites, you can think of each ActionScript
> test suite as a Composite <http://c2.com/cgi/wiki?CompositePattern>structure that contains any number of TestCases and other TestSuites. Each
> of the aforementioned tools will automate construction of test suites so
> that you can be assured that all of your tests are being executed. The only
> time I manually interact with these files is when debugging some feature or
> set of features, otherwise I usually just edit the Test Runner's start call
> to execute the test case that I'm currently interested in, and then edit it
> back to running AllTests before I check in.
>
> Hope that helps!
>
> Please keep the questions coming, I'm certain you're not the only one.
>
>
> Luke Bayes
> www.asunit.org
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
> your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Asunit-users mailing list
> Asu...@li...
> https://lists.sourceforge.net/lists/listinfo/asunit-users
>
>

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

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

[Robert S. <rob...@gm...>]

Luke,

I had one more thought about why I default to putting tests in their own
little folders inside my packages.  Because I am a student and an employee,
unfortunately, I don't have that much time to spend developing libraries for
public consumption.  Most of my code is proprietary.  So in my work
environment, having tests in my packages pays big dividends for internal
customers (boss, cohorts, etc.) because the tests are in close proximity to
the corresponding source in the file system and they are not cluttering up
the source directory.   And since my co-developers are never going to be
concerned about the source and tests living in the same package, there is no
need to think about how to extract the tests from the package directory.  So
I  guess because of the nature of my work, that is just the pattern  I've
adopted.

Robert

On 4/9/07, Luke Bayes <lb...@pa...> wrote:
>
> 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
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
> your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Asunit-users mailing list
> Asu...@li...
> https://lists.sourceforge.net/lists/listinfo/asunit-users
>
>

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

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

Hey Robert,

That definitely makes sense to me. I still prefer the sibling paths for two
reasons:

a) Import statements / class scope: It is more applicable in AS3 than AS2,
but classes are scoped to their packages and classes found in the same
package don't need imports. This makes refactoring just a tiny bit less
expensive when it involves renaming or moving classes around. Especially
since classes that reference one another tend to be found in the same
packages.

I believe that in Java/.NET, there are some values that can only be accesses
by classes in the same package and this is the argument that appears to have
led most JUnit users to this approach since granting this access to test
cases made testing much easier. The decision for those other communities
leads into my second justification...

c) Consistency: In informal, ad-hoc reading, it "seemed" like more people
did it that way. Of course I concede that this is debatable since I didn't
have actual scientific findings or anything. It just seemed like more
tutorials, books and discussions revolved around this approach.

With that said, my feeling is that sometimes, "It looks better to me", is a
perfectly valid argument and need only be weighed against how much time it
may cost.

In the case of AsUnit, your approach is incompatible with the conventions
supported in any of our provided tools. If none of these tools are
particularly appealing for you in the first place (Which is perfectly
valid), your approach will cost you very little. If you wanted to use these
tools, you'll need to modify them to support your approach, which may cost
quite a lot of time.

Either way, the decisions about project layout are obviously, entirely
yours. The AsUnit framework itself makes no assumptions of that kind.

You should know that with AsProject, we're moving a little closer to the
Rails ideas about convention over configuration, and standardizing on a
project layout that is essentially expected for the tools to work properly.
In the future, these tools may provide enough of a productivity gain to
justify the change. The big win will come when working on teams, and other
team members are able to instantly get up and running on your project
because they already know where things are.

Those days are still quite a way off so there's not a lot of pressure at the
moment, just something to keep in mind.

In closing, I really appreciate you taking the time on this list Robert and
I hope to hear more from you as you get further along with AsUnit.


Thanks,

Luke Bayes
www.asunit.org