asunit-users — This list is for the users of AsUnit that are not involved in it's development.

Re: [Asunit-users] Testing view classes (subclasses of MovieClip and the likes)

[Marcelo de M. S. <cel...@gm...>]

Hi Luke, thanks for the reply :)

It is still not clear to me the role of MovieClip classes on asunit unit
tests. From what I've been reading about Unit Testing so far, I can
understand that visual entities should not be unit tested directly. Instead,
the business classes that are used by it should be tested and I don't think
business classes should inherit MovieClip (am I misunderstanding something
here?).

But let's say I really want to instantiate a MovieClip class on my unit
test. The XUL UI feature you described is for creating mock objects for
MovieClip classes, right? I'm asking this becouse it would be too much of a
stress to try to instantiate a regular "non-serializable" MovieClip class as
it depends on assets that are not present on the test swf library (and
should not be present, I'm almost sure!).

Cheers,

Marcelo.

On 12/29/06, Luke Bayes <lb...@gm...> wrote:
>
> Sorry for the delayed response, been away from the gmail for a bit...
>
> It seems you guys are getting it sorted out, and the only thing I wanted
> to add is that the TestCase class does have a helper method for
> attachMovie... This method gives you the ability to ignore the instance name
> and depth arguments which is critical when building out large test suites.
>
> TestCase does not extend MovieClip, but it delegates responsibility for
> clip creation to the Runner - that does extend MovieClip.
>
> You should be able to see this usage in action using the XUL UI by
> choosing "Make Class Serializable", but for those of you not on that system,
> it's something like this (untested pseudo-code):
>
> public function setUp():Void {
>     var initObject:Object = {param1:value1, param2:value2};
>     instance = attachMovie(SomeClassName.linkageId, initObject);
> }
>
> public function tearDown():Void {
>     instance.removeMovieClip();
>     delete instance;
> }
>
> public function testSomeMethod():Void {
>     assertEquals("foo", instance.getFooString());
> }
>
>
> Using this utility method will help get rid of massive amounts of
> duplicate code in your test suites, and it has the added benefit of
> automagically overcoming some bugs in the Flash Player that have to do with
> "removed" clips not actually being destroyed synchronously.
>
>
> Good luck,
>
>
> 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] Testing view classes (subclasses of MovieClip and the likes)

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

Sorry for the delayed response, been away from the gmail for a bit...

It seems you guys are getting it sorted out, and the only thing I wanted to
add is that the TestCase class does have a helper method for attachMovie...
This method gives you the ability to ignore the instance name and depth
arguments which is critical when building out large test suites.

TestCase does not extend MovieClip, but it delegates responsibility for clip
creation to the Runner - that does extend MovieClip.

You should be able to see this usage in action using the XUL UI by choosing
"Make Class Serializable", but for those of you not on that system, it's
something like this (untested pseudo-code):

public function setUp():Void {
    var initObject:Object = {param1:value1, param2:value2};
    instance = attachMovie(SomeClassName.linkageId, initObject);
}

public function tearDown():Void {
    instance.removeMovieClip();
    delete instance;
}

public function testSomeMethod():Void {
    assertEquals("foo", instance.getFooString());
}


Using this utility method will help get rid of massive amounts of duplicate
code in your test suites, and it has the added benefit of automagically
overcoming some bugs in the Flash Player that have to do with "removed"
clips not actually being destroyed synchronously.


Good luck,


Luke Bayes
www.asunit.org

Re: [Asunit-users] Testing view classes (subclasses of MovieClip and the likes)

[Marcelo de M. S. <cel...@gm...>]

Let's take a classic MVC application.

I see I've got two approaches:
 * Instantiate the view on the test swf and test its execution flow;
 * Test differente aspects of the view from the "inside" out (using the
different classes that makes it, leaving out the visual aspects)

After some thinking, I concluded (I may be wrong, of course) that attaching
a MovieClip to the test swf is cumbersome. After all, I can test every
single aspect of a view without needing this view (including initialization
code), that's the purpose of MVC, right? The view, in this case, would be
the output of TestRunner ;)

Marcelo.

On 12/27/06, David Ham <em...@da...> wrote:
>
> Marcelo,
>
> If your class someClass does not have any graphics in it (components and
> other code-only items are OK), you can create one programmatically without
> having it in your Library. Read this:
>
>
> http://www.peterjoel.com/blog/index.php?archive=2004_01_01_archive.xml&showC
> omments=107550841406346131
>
> Basically, you declare these vars in your class:
>
> static var symbolName:String = "__Packages.com.foo.someClass";
> static var symbolOwner:Object = someClass;
>
> // associate the symbol to the class when the class is defined
> static var symbolLinked = Object.registerClass(symbolName, symbolOwner);
>
> The bit about '__Packages' tells Flash the symbol is in your library. From
> what I understand, it's kind of a hack, but it's OK for use in your test
> harness.
>
> I think you can also use ASUnit to create a class that extends MovieClip.
> Click the "Make class serializable" box and create the class, see what the
> generated class looks like.
>
>
> > * If I will be attaching the MovieClip "someClass", it will have to be
> present
> > on the swf's library. Currently my test swf is only an empty swf;
> >
> > I see I would have to create this swf using swfmill (or the Flash IDE)
> and
> > then add a clip to the library, right?
>
> Nope, if you use the __Packages hack it should work with an empty library.
> However, if your class uses symbols that contain graphics, yes, you'll
> need
> to create it in your production FLA and copy it into your test FLA's
> Library. A bit kludgey but it works.
> >
> > * Do you think this approach of attaching MovieClip is ok? Doesn't
> test-driven
> > design enourage to separate the view from the business logic?
>
> I am still learning about TDD, but separating the view from the business
> logic is good model-view-controller practice, and is not necessarily part
> of
> TDD. TDD is more about programming by intention. You think of something
> your
> code is supposed to do, then you write a test that would verify your
> desired
> outcome, run the test to watch it fail, then write only as much code as
> necessary to get the test to pass. Once your tests are all green you
> simplify and refactor as necessary to make your code observe best
> practices
> like separating the view from business logic. The emphasis is on quick
> iterations, the simplest code, and a growing suite of tests that verify
> your
> functionality.
>
> Or at least, that's what I gather from my recent reading on the subject;
> my
> apologies to the TDD veterans if I am mis-representing anything.
>
> Good luck,
>
> OK
> DAH
>
>
>
>
>
>
> -------------------------------------------------------------------------
> 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] Testing view classes (subclasses of MovieClip and the likes)

[David H. <em...@da...>]

Marcelo,

If your class someClass does not have any graphics in it (components and
other code-only items are OK), you can create one programmatically without
having it in your Library. Read this:

http://www.peterjoel.com/blog/index.php?archive=2004_01_01_archive.xml&showC
omments=107550841406346131

Basically, you declare these vars in your class:

static var symbolName:String = "__Packages.com.foo.someClass";
static var symbolOwner:Object = someClass;

 // associate the symbol to the class when the class is defined
static var symbolLinked = Object.registerClass(symbolName, symbolOwner);

The bit about '__Packages' tells Flash the symbol is in your library. From
what I understand, it's kind of a hack, but it's OK for use in your test
harness.

I think you can also use ASUnit to create a class that extends MovieClip.
Click the "Make class serializable" box and create the class, see what the
generated class looks like.


> * If I will be attaching the MovieClip "someClass", it will have to be present
> on the swf's library. Currently my test swf is only an empty swf;
> 
> I see I would have to create this swf using swfmill (or the Flash IDE) and
> then add a clip to the library, right?

Nope, if you use the __Packages hack it should work with an empty library.
However, if your class uses symbols that contain graphics, yes, you'll need
to create it in your production FLA and copy it into your test FLA's
Library. A bit kludgey but it works.
> 
> * Do you think this approach of attaching MovieClip is ok? Doesn't test-driven
> design enourage to separate the view from the business logic?

I am still learning about TDD, but separating the view from the business
logic is good model-view-controller practice, and is not necessarily part of
TDD. TDD is more about programming by intention. You think of something your
code is supposed to do, then you write a test that would verify your desired
outcome, run the test to watch it fail, then write only as much code as
necessary to get the test to pass. Once your tests are all green you
simplify and refactor as necessary to make your code observe best practices
like separating the view from business logic. The emphasis is on quick
iterations, the simplest code, and a growing suite of tests that verify your
functionality.

Or at least, that's what I gather from my recent reading on the subject; my
apologies to the TDD veterans if I am mis-representing anything.

 Good luck,

OK
DAH

Re: [Asunit-users] Testing view classes (subclasses of MovieClip and the likes)

[Marcelo de M. S. <cel...@gm...>]

Hi David, thanks a lot for the reply.

There are a few points that I'd like to clarify:

* If I will be attaching the MovieClip "someClass", it will have to be
present on the swf's library. Currently my test swf is only an empty swf;

I see I would have to create this swf using swfmill (or the Flash IDE) and
then add a clip to the library, right?

* Do you think this approach of attaching MovieClip is ok? Doesn't
test-driven design enourage to separate the view from the business logic?

Thanks!

Marcelo.

On 12/27/06, David Ham <em...@da...> wrote:
>
> Marcelo,
>
> I think you have two options. First, I think you are OK in creating an
> instance of your class on the test swf, but I have had better luck in
> creating an empty movieclip and then attaching my new class to that. Then,
> you create an instance of the class you are testing via an attachMovie()
> on
> the test clip, and cast it as a type of the class you are testing.
>
> private var testClip:MovieClip;
> private var instance:myClass
>
> function setUp():Void {
>     testClip = _root.createEmptyMovieClip( "testClip", 100 );
>     instance = myClass( testClip.attachMovie("someClass", "someClass_mc",
> 0)
> );
> }
>
>
> You can also use createClassObject() if your class extends UIObject.
>
> Be sure you properly remove all the clips in tearDown() that you created
> in
> setUp() or they will clutter up your test SWF.
>
> Hope this helps,
>
> OK
> DAH
>
>
>
>
> -------------------------------------------------------------------------
> 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] Testing view classes (subclasses of MovieClip and the likes)

[David H. <em...@da...>]

Marcelo,

I think you have two options. First, I think you are OK in creating an
instance of your class on the test swf, but I have had better luck in
creating an empty movieclip and then attaching my new class to that. Then,
you create an instance of the class you are testing via an attachMovie() on
the test clip, and cast it as a type of the class you are testing.

private var testClip:MovieClip;
private var instance:myClass

function setUp():Void {
    testClip = _root.createEmptyMovieClip( "testClip", 100 );
    instance = myClass( testClip.attachMovie("someClass", "someClass_mc", 0)
);
}


You can also use createClassObject() if your class extends UIObject.

Be sure you properly remove all the clips in tearDown() that you created in
setUp() or they will clutter up your test SWF.

Hope this helps,

OK
DAH

Re: [Asunit-users] Testing view classes (subclasses of MovieClip and the likes)

[Marcelo de M. S. <cel...@gm...>]

anyone? :/

On 12/25/06, Marcelo de Moraes Serpa <cel...@gm...> wrote:
>
> Hi,
>
> I'm just starting with unit testing, so, sorry if my questions sound
> stupid or something alike.
>
> I have a Preloader class which is a simple MovieClip subclass that gets
> compiled into Preloader.swf. This Preloader only uses native Flash Player
> resouces ( i.e: no additional as2 classes). It has a very simple execution
> flow, but I'd like to test it (try to load the other swf, does the code that
> loads the swf work? Are all the MovieClipLoader's callbacks being called?
> The data sent from swfobject is there?) . However, I'm confused on how I
> would go on testing this class as it's a MovieClip subclass.
>
> So, I have the PreloaderTest class:
>
> import asunit.framework.TestCase;
>
> class testes.PreloaderTest extends TestCase
> {
>    private var _PreloaderClip:MovieClip;
>
>    public function PreloaderTest(testMethod:String)
>    {
>       super(testMethod);
>    }
>
>    public function setUp():Void
>    {
>       //Here, I tried creating an empty MovieClip to the root of the test
> swf...
>       _PreloaderClip =
> _root.createEmptyMovieClip("preloader_clip",_root.getNextHightestDepth());
>
>       //But then I realized that this MovieClip needed to be registered to
> the correspondent Preloader class! ... too much of a hassle... As this clip
> isn't on the library (it has been
>       //created) I would need to do dirty prototype tricks to get the
> class registered. I know it's not that difficult (although I can't remember
> how to do it) but I felt that it isn't the way
>       //to go for testing. SHould I just create an instance of the
> Preloader class using the new notation?
>
>    }
>
>    public function tearDown():Void
>    {
>    }
>
>
> }
>
> I'm really confused... Maybe I shouldn't be testing this class. Maybe I
> should rethink the design and make it more "test-friendly", but how?.
>
>
> Any help would be greatly appreciated!
>
> Thanks in advance,
>
> Marcelo.

[Asunit-users] Testing view classes (subclasses of MovieClip and the likes)

[Marcelo de M. S. <cel...@gm...>]

Hi,

I'm just starting with unit testing, so, sorry if my questions sound stupid
or something alike.

I have a Preloader class which is a simple MovieClip subclass that gets
compiled into Preloader.swf. This Preloader only uses native Flash Player
resouces (i.e: no additional as2 classes). It has a very simple execution
flow, but I'd like to test it (try to load the other swf, does the code that
loads the swf work? Are all the MovieClipLoader's callbacks being called?
The data sent from swfobject is there?) . However, I'm confused on how I
would go on testing this class as it's a MovieClip subclass.

So, I have the PreloaderTest class:

import asunit.framework.TestCase;

class testes.PreloaderTest extends TestCase
{
   private var _PreloaderClip:MovieClip;

   public function PreloaderTest(testMethod:String)
   {
      super(testMethod);
   }

   public function setUp():Void
   {
      //Here, I tried creating an empty MovieClip to the root of the test
swf...
      _PreloaderClip =
_root.createEmptyMovieClip("preloader_clip",_root.getNextHightestDepth());

      //But then I realized that this MovieClip needed to be registered to
the correspondent Preloader class! ... too much of a hassle... As this clip
isn't on the library (it has been
      //created) I would need to do dirty prototype tricks to get the class
registered. I know it's not that difficult (although I can't remember how to
do it) but I felt that it isn't the way
      //to go for testing. SHould I just create an instance of the Preloader
class using the new notation?

   }

   public function tearDown():Void
   {
   }


}

I'm really confused... Maybe I shouldn't be testing this class. Maybe I
should rethink the design and make it more "test-friendly", but how?.


Any help would be greatly appreciated!

Thanks in advance,

Marcelo.

Re: [Asunit-users] Mock-objects

[Marcelo de M. S. <cel...@gm...>]

Ah, that's much more clear now, thanks a lot for helping Luke!

On 12/19/06, Luke Bayes <lb...@gm...> wrote:
>
>
> Hmmm, I thought this would be the greatest benefit as it would allow me to
> > really focus on one thing at a time and then adjust the little
> > inconsistencies later - isn't that what test-driven all about? (Design
> > first, implement later, in this case implement the server-side later)
> >
> > Marcelo.
>
>
> Actually - TDD is about combining the design and implementation process
> into a series of small steps. It helps us avoid making big design decisions
> about how we think an application will work and instead lets us focus in on
> implementing the "next most important thing".
>
> With all that said, of course TDD does help you more cleanly separate the
> different layers of an application, and writing tests around a service stub
> (or mock) is highly recommended. The only issue I was trying to caution
> against is if there were some other developers building the server
> concurrently, make sure you're integrating early and often - as these two
> layers often get implemented much differently than they're initially
> designed. If you're building the sever *after* the client, this would be
> much less of a problem.
>
>
> Thanks,
>
>
> Luke
>
>
> -------------------------------------------------------------------------
> 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] Mock-objects

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

> Hmmm, I thought this would be the greatest benefit as it would allow me to
> really focus on one thing at a time and then adjust the little
> inconsistencies later - isn't that what test-driven all about? (Design
> first, implement later, in this case implement the server-side later)
>
> Marcelo.


Actually - TDD is about combining the design and implementation process into
a series of small steps. It helps us avoid making big design decisions about
how we think an application will work and instead lets us focus in on
implementing the "next most important thing".

With all that said, of course TDD does help you more cleanly separate the
different layers of an application, and writing tests around a service stub
(or mock) is highly recommended. The only issue I was trying to caution
against is if there were some other developers building the server
concurrently, make sure you're integrating early and often - as these two
layers often get implemented much differently than they're initially
designed. If you're building the sever *after* the client, this would be
much less of a problem.


Thanks,


Luke

[Asunit-users] New icon for AsUnit-X

[Aral B. <ar...@ar...>]

Thanks to Jason Bednarik, AsUnit-X now has a new icon.

Blog post/download link:
http://aralbalkan.com/812

All the best,
Aral

Re: [Asunit-users] Mock-objects

[Marcelo de M. S. <cel...@gm...>]

Hi Luke, thanks for the comprehensive explanation,

>As far as building the client completely independently of the server, I
would encourage you to integrate early and often. It's far too easy >to have
these two pieces fall out of sync, or have unexpected needs arise during
actual usage. A set of APIs that make sense in theory >often don't make
nearly as much sense in practice.

Hmmm, I thought this would be the greatest benefit as it would allow me to
really focus on one thing at a time and then adjust the little
inconsistencies later - isn't that what test-driven all about? (Design
first, implement later, in this case implement the server-side later)

Marcelo.

On 12/18/06, Luke Bayes <lb...@gm...> wrote:
>
> Hey Marcelo,
>
> If you're using the XUL UI, you can ask it to create a Mock directly in
> the interface and that should get it to generate the class under test, the
> mock that extends it and a test case that uses the mock instead of the
> class.
>
> We generally use mocks for our service layer and have them return faux /
> expected results.
>
> The idea is basically, that you have a Service class and a ServiceMock
> class that extends it. You can override each of the methods that call out to
> the network and create a faux result set - hopefully one that makes sense.
>
> As far as building the client completely independently of the server, I
> would encourage you to integrate early and often. It's far too easy to have
> these two pieces fall out of sync, or have unexpected needs arise during
> actual usage. A set of APIs that make sense in theory often don't make
> nearly as much sense in practice.
>
> The primary benefit of mocking the service layer is that when someone on
> one team or another breaks on half of the application (client or server),
> the other team isn't held up waiting for a patch.
>
> As far as specific examples go, I'm not sure if there are any out there
> right now - basically, you just extend the class under test, call the new
> subclass ClassNameMock and use it in your TestCases... There are a couple of
> good reasons to do this and many people name this object differently based
> on it's purpose ( mock vs. stub<http://www.martinfowler.com/articles/mocksArentStubs.html>),
> but I generally just name them 'mock' and get on with the task at hand.
>
> Please let me know if you need more clarification, and I'll see what we
> can do.
>
>
> 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
>
>
>

[Asunit-users] as25 TestRunner only reporting the last TestCase

[Ryan C. <ry...@fi...>]

Hey guys, here's a little bug...

When running a bunch of TestCase's in a suite extending TestRunner,  
the results printed are only from the last TestCase. For example,

"Tests run: 7,  Failures: 0,  Errors: 0"

when I should be seeing

"Tests run: 380,  Failures: 2,  Errors: 0"


Here is a patch which changes BaseTestRunner to use one instance of  
TestResult for all TestCases instead of one per TestCase. It makes  
things work like I expect... or am I missing something?

(patch pasted in case attachments don't go through...)

Index: asunit/runner/BaseTestRunner.as
===================================================================
--- asunit/runner/BaseTestRunner.as	(revision 143)
+++ asunit/runner/BaseTestRunner.as	(working copy)
@@ -9,6 +9,7 @@
	private static var clipContext:MovieClip;
	private var printer:IResultPrinter;
	private var intervalId:Number;
+	private var result:TestResult;
	
	public function BaseTestRunner(printerReference:Function) {
		if(printerReference == undefined) {
@@ -19,6 +20,8 @@
		instance = this;
		setClipContext(_root);
		setPrinter(createResultPrinter(printerReference));
+		result = new TestResult();
+		result.addListener(getPrinter());
	}
	public static function getFilteredTrace(stack:String):String {
@@ -37,8 +40,6 @@
	
	public function doRun(suite:Test, showTrace:Boolean):TestResult {
		try {
-			var result:TestResult = new TestResult();
-			result.addListener(getPrinter());
			var startTime:Number = getTimer();
			suite.setResult(result);
			suite.setContext(getClipContext());

Re: [Asunit-users] Mock-objects

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

Hey Marcelo,

If you're using the XUL UI, you can ask it to create a Mock directly in the
interface and that should get it to generate the class under test, the mock
that extends it and a test case that uses the mock instead of the class.

We generally use mocks for our service layer and have them return faux /
expected results.

The idea is basically, that you have a Service class and a ServiceMock class
that extends it. You can override each of the methods that call out to the
network and create a faux result set - hopefully one that makes sense.

As far as building the client completely independently of the server, I
would encourage you to integrate early and often. It's far too easy to have
these two pieces fall out of sync, or have unexpected needs arise during
actual usage. A set of APIs that make sense in theory often don't make
nearly as much sense in practice.

The primary benefit of mocking the service layer is that when someone on one
team or another breaks on half of the application (client or server), the
other team isn't held up waiting for a patch.

As far as specific examples go, I'm not sure if there are any out there
right now - basically, you just extend the class under test, call the new
subclass ClassNameMock and use it in your TestCases... There are a couple of
good reasons to do this and many people name this object differently based
on it's purpose (mock vs.
stub<http://www.martinfowler.com/articles/mocksArentStubs.html>),
but I generally just name them 'mock' and get on with the task at hand.

Please let me know if you need more clarification, and I'll see what we can
do.


Thanks,


Luke Bayes
www.asunit.org

[Asunit-users] Mock-objects

[Marcelo de M. S. <cel...@gm...>]

Hi folks!

Where could I find some more information and samples on using the asunit
mock objects API ? I know the concept of mock-objects, however I'm not sure
how to use it together with asunit. I want to follow the "test-driven"
methodology and also develop the client side app first and feed it with mock
objects as need and then later "plug" the back-end. I know As2Lib has a
mock-object API, so, I'd also like to know which to use!

Thanks in advance,

Marcelo.

[Asunit-users] AsUnit XUL UI finally on OS X (introducing AsUnit-X

[Aral B. <ar...@ar...>]

Hi everyone,

A quick heads up that I made a standalone OS X app from the XUL UI  
for AsUnit today and packaged it up in a DMG. It's released under the  
same license as AsUnit (LGPL).

Hopefully, this should help make AsUnit more accessible to Mac-based  
developers.

Once again, big props to Luke and Ali for making it all possible in  
the first place :)

You can read all about AsUnit-X and download it from:
http://aralbalkan.com/798

Aral
PS. Apologies for the cross-post but there may be people on the  
OSFlash who are not on the AsUnit mailing list that may benefit from  
this also.

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

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

[David H. <em...@da...>]

In a related 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?

OK
DAH

[Asunit-users] ASUnit 101: Testing interface elements

[David H. <em...@da...>]

So I have a test harness in place and it is working nicely for testing the
setting and getting of particular values. So far so good!

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?

Thanks as always,

OK
DAH

Re: [Asunit-users] ASUnit 101: Where do I start?

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

Thanks David.

I really appreciate the kind words and I'm glad to be of some help.


Thanks,

Luke
www.asunit.org

Re: [Asunit-users] ASUnit 101: Where do I start?

[David H. <em...@da...>]

Luke, 

This is awesome.

My experience in using design patterns has been exclusively in implementing
variations on the patterns Colin Moock describes in his books, but he draws
on the Gang of Four book, so I should probably go there next. And the Kent
Beck books are in my shopping cart as we speak.

I have read about story cards before and will write some up tomorrow
morning. I did my first few cycles of test-code-simplify today and while
they were somewhat clumsy, I am starting to see how it should work.

I do have some other questions, but I will put them in new threads because
the topics are different. As I wade into this methodology, I start to see
hints of the answers to my questions, and the more I spell the questions out
the easier it is to see the answers. I do, however, have a long way to go.

Thanks as always for your generosity and insight.

OK
DAH

Re: [Asunit-users] ASUnit 101: AsUnit Book

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

Hey David,

Thanks for adding content to the "Using
AsUnit<http://en.wikibooks.org/wiki/Using_AsUnit>"
book, please keep up the good work!

Ali and I are hoping to help drive the organization and structure, but we're
really hoping that the community will contribute the content. If anyone is
interested, please feel free to make edits and additions wherever necessary.

Hopefully this will grow into a useful resource for others!



Thanks,

Luke Bayes
www.asunit.org

Re: [Asunit-users] ASUnit 101: Where do I start?

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

David,

Please keep asking questions. You are definitely not alone with these!

The question of where to start is actually the most important and of course
the most difficult to answer.

I have been sitting here for an hour writing paragraphs of prose and
deleting them over and over again trying to find something meaningful and
yet concise to say. Following is the best I can come up with and
unfortunately still isn't very concise.

Ali and I practice Extreme Programming <http://extremeprogramming.org/>.
This is a kind-of-scary, sort-of-strange, poorly-named, pretty-fad-sounding
development process that embarrasses me every time I hear it's name stated
out loud. I suspect the over-forty crowd responsible for the naming watched
too much TV and didn't realize that this term is considered ridiculous by
the rest of us. We usually prefer to lay claim to "Agile" development, but
the truth is, we work pretty hard at just about all of the details outlined
in XP.

Apologies aside, our experience demonstrated in no uncertain terms that Big
Design Up Front <http://c2.com/cgi/wiki?BigDesignUpFront> (or the waterfall
process) simply did not work for the kinds of projects that we worked on.
Ali and I spent a considerable amount of time looking into alternatives and
the one we settled on was XP. I'm not in much of a position to comment on
other approaches, and I'm not naive enough to think that there is only one
way to do something. I recognize that XP is not a "Silver
Bullet<http://c2.com/cgi/wiki?SilverBullet>",
and not appropriate for every project. For me - it has proven to be the best
way - that I have found - to get through a project from beginning to end and
wind up with something that is launch-worthy and a client that is relatively
excited about the value they received.

We were able to slowly move into XP one step at a time. We started with Unit
Testing <http://c2.com/cgi/wiki?UnitTest> and
NoteCards<http://c2.com/cgi/wiki?ManagingCards>,
moved into Iterative
Releases<http://extremeprogramming.org/rules/releaseoften.html>,
slid toward actual Test-Driven
Development<http://extremeprogramming.org/rules/testfirst.html>,
then began seeing value in Pair
Programming<http://extremeprogramming.org/rules/pair.html>.
Eventually, we had the privilege of working on a project with a firm that
already had XP development implemented, and this experience helped ground us
in the whole picture. I'm not sure how other people do it, but a kinder,
gentler approach worked well for us and helped us avoid becoming overwhelmed
and reactionary. I tend to suffer from a somewhat enlarged ego and probably
wouldn't have done well if someone had forced me to suddenly run a project
under the full range of XP practices<http://extremeprogramming.org/rules.html>
.

I wanted to go into all of this, because it colors my response to "where to
start"...

I happen to be a voracious reader and can't help but recommend a couple of
books that truly helped me answer this question for myself:

The book "Test Driven Development by
Example<http://www.amazon.com/Test-Driven-Development-Addison-Wesley-Signature/dp/0321146530/sr=8-1/qid=1164773372/ref=pd_bbs_sr_1/104-2146572-6188719?ie=UTF8&s=books>"
written by Kent Beck <http://c2.com/cgi/wiki?KentBeck> (the founder of XP)
is an excellent read and leaves a lot of the ancillary details of XP out,
but gives a strong introduction to how this one part works. I have read this
book over and over again and yet I know there is more information in there
waiting to be gleaned.

The other major book that impacted my development deeply was "Design
Patterns<http://www.amazon.com/Design-Patterns-Object-Oriented-Addison-Wesley-Professional/dp/0201633612/ref=cm_lm_fullview_prod_1/104-2146572-6188719>"
by the Gang of Four. This book is so dense and academic that I couldn't
understand much more than the introduction the first 5 or 6 times I sat down
to read it. Ali and I finally broke down and created a Design Patterns Study
Group <http://www.industriallogic.com/papers/learning.html> in order to more
fully understand what these guys were trying to teach us. I don't think I
have ever learned so much so quickly, and can't recommend doing this
strongly enough.

To your specific question of whether you should dig deep and start writing
and testing features like a Polygon, or try to stay general and start with
higher-level features like "Create Room", I have to say that my answer is
sadly - both.

What we try to do when we start a project is to stand over a big table and
write down every feature that comes to mind - one feature to each note card.
Some of these note cards look like "user stories", some of them are simply
technical details or class names and some of them are essentially
components. The best term that I can come up with to describe them are
"modules". They're basically units of functionality.

When we're with the customer, we talk about "User Stories" or "Features"
like "Login" or "Display a list of thingys", or "edit a single thingy". But
when we're note carding, we usually talk about components and entities. We
don't try to note card every single class that we're going to build, but
usually wind up seeing classes emerge from this process. When we're done, we
have a pretty good idea of how the next iteration (week or two) is going to
look. If we want "Login" to work, we'll need a user name and password
TextInput control. We'll need some kind of submit button, failure feedback,
a panel of some sort, and hopefully some mechanism where we can store the
fact that someone has in fact logged in.

After note carding a user story like this, we usually sit down and start
writing components. What should a TextInput control look like to support
login? NOT how many features could I possibly ever need from a TextInput
control... This is a critical and major problem that Ali and I both have
difficulty balancing in every single project. It is so enticing to build the
world's best TextInput control - one that does everything you could ever
think of. But - for this iteration - we need Login, not a scalable, HTML
WYSIWYG text editor. It's like building a gesture of your application. You
start from the outside with general features, and you instantly drill deep
down into the details - but the crux is to not spend too much time worrying
over those details. TDD drives you back to the feature as soon as the detail
work is "good enough".

The really tough problem is trying to figure out how general a feature to
start with, so that you don't need 500 details in order to even begin.
That's where note cards come in really handy. They help you think about
things in a more modular way and take on a group of tasks that can be
accomplished in an afternoon or two. If you find yourself immersed in a task
that you thought would take an afternoon, and now it's 3 days later, at
least you know where you are for this iteration. If you find that happening
every time you sit down, you can start to finally address your enduring
optimism (I'm still working on that by the way). The idea is that you're
building and delivering useful functionality every day.

The real benefit to this type of process comes when the business people
crawl up to your desk in a panic because they need something different from
what they used to think they needed, and you're able to say - "That's not a
problem, I've only built the things that you've already seen, and I'm happy
to talk about this new feature that you're interested in, let's try to
figure out what you need right now."

Well, I think I've run off at the mouth long enough and hopefully some of
the links here will help to better explain what I'm rambling on and on
about...


Good Luck,


Luke
www.asunit.org

[Asunit-users] ASUnit 101: Where do I start?

[David H. <em...@da...>]

Luke,

If you don=B9t mind all my n00b questions, I=B9ll keep asking them! I will
prefix them with =8CASUnit 101=B9 and then I and others can find them later.

I have ASUnit installed and working, and my app structure is like this:

/assets --> for images and other compile time assets
/deploy --> for SWFs, HTML, XML, and other runtime items
/source --> FLA and classes
/test --> ASUnit framework and test harness code

The app I am building is a room layout tool; users can lay out walls, and
arrange room objects like furniture and cabinets. The output is an XML-base=
d
description of the room and a series of area measurements. I have a rough
MVC structure planned, as well as an object model.

But where do I start with my test-code-simplify cycle? It seems that every
object requires something that would come from another object, and if I wan=
t
my tests to mirror real-world conditions (which they should do, yes?) I nee=
d
to create those objects first and then use them in my later tests.

Should I start at the top, with my main application class, and work inwards=
,
or should I start with my smallest classes (like Polygon, which will be use=
d
by the Room object), and build out, adding new classes as I need them?

I ask because it already seems like a lot of extra work. I don't know how t=
o
think of it in test-first terms yet. Normally I would just sketch out my MV=
C
structure, and then jump into building it, using trace() to check my work a=
s
I go. But now I am trying to think of tests for each little method and
property, tests that will become part of the permanent test harness, and
it's such a different way to think that I am sort of stymied by it.

I understand that TDD is supposed to provide a more understandable and
maintainable app, a leaner codebase, and an automated test suite, at the
expense of a little extra time and extra code produced, in the form of all
the test cases. I am just confused as to how to start

As always, any help you or others can provide is greatly appreciated. I wil=
l
adapt what I learn and put it in the wikiBook.

OK
DAH

BTW, I am trying to follow the Test First Guidelines as described here:
http://xprogramming.com/xpmag/testFirstGuidelines.htm

Re: [Asunit-users] Problems getting started

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

Hey David,

Thanks for the feedback. We would definitely appreciate any help we can get
with Docs and Macs. I bought a mac mini earlier this year, but am definitely
not quite up to speed with using it.

We desperately need a mac installer for the XUL UI. If you can figure out
how to build a mac package that includes xulrunner and our application so
that mac users can just double-click to install, it would be immensely
appreciated.

As far as documentation goes, Ali and I just decided to go ahead and stub
out a WikiBook for AsUnit. I think that this will give us a good
collaborative environment for writing useful documentation. Please check out
the link:

http://en.wikibooks.org/wiki/Using_AsUnit

I have thrown together a rough structure that might work, but any feedback
or contributions would be greatly appreciated. Please feel free to just edit
the page if you have something to add.


Thanks,


Luke Bayes
www.asunit.org