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