|
From: Marcelo de M. S. <cel...@gm...> - 2006-12-25 22:08:19
|
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.
|
|
From: Marcelo de M. S. <cel...@gm...> - 2006-12-27 17:55:30
|
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.
|
|
From: David H. <em...@da...> - 2006-12-27 18:21:38
|
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
|
|
From: Marcelo de M. S. <cel...@gm...> - 2006-12-27 19:36:26
|
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
>
|
|
From: David H. <em...@da...> - 2006-12-27 20:00:06
|
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 |
|
From: Marcelo de M. S. <cel...@gm...> - 2006-12-27 20:08:54
|
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 > |
|
From: Luke B. <lb...@gm...> - 2006-12-29 07:28:24
|
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
|
|
From: Marcelo de M. S. <cel...@gm...> - 2006-12-29 10:19:59
|
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
>
>
>
|
|
From: Luke B. <lb...@gm...> - 2006-12-29 19:19:06
|
Hey Marcelo, There are a couple of issues you're talking about here, I'm going to restate them a little differently, please let me know if this is inaccurate. 1) Should I ever write a unit test for a visual entity? Yes. There are definitely times when views have code. Even using MVC, the view is responsible for some work and unit testing can verify that this work is being done as expected. 2) How do I structure an application for unit testing? Ali and I spent a considerable amount of time thinking about this problem, and after quite a bit of trial and error, we realized that one of the most important aspects to testing is that the environment your test harness operates in should be as nearly identical to your production environment as possible. This includes library assets, frameworks, etc... For example, Macromedia's components manipulate some core object prototypes, add functions to _global and place assets on _root in a very high level which affects our ability to use _root.getNextHighestDepth(). IF we are using components in our application, but fail to load that library into our test swf, we will see behaviors in production that are very different from those that we find in our tests. We generally try to avoid using a fla file if at all possible, but if we are forced to use a .fla file for a project, the most important thing that we do, is avoid doing any real work on the main timeline. If we have some animation or some frame-based work that needs done, we put it into a MovieClip. The main timeline of our .fla files generally has one line of ActionScript. This line is usually switched from running our application main function to running our test suite main function. This has the added benefit of allowing us to point MTASC at either of these main functions and simply swallow the MMC-compiled swf file. // SomeApplication.main(); SomeApplicationRunner.main(); I hope that helps. Luke Bayes www.asunit.org On 12/29/06, Marcelo de Moraes Serpa wrote: > > 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. > > |
|
From: Marcelo de M. S. <cel...@gm...> - 2006-12-29 19:39:38
|
> > This line is usually switched from running our application main function > to running our test suite main function I couldn't really understand, Luke. The way I'm doing right now is having a test swf and that is all. The way you put it, seems like you mix test code with production code, is that right? Let me explain better how I've set up my unit testing workflow: I'm using AS2ANT unittest task. So, I compile the TestRunner into a swf file and run it before proceeding with the rest of the build. I have two identical project trees - one for the production source files and one for theses classes' test classes, like this: * com.cconline.views.IndexView * tests.com.cconline.views.IndexViewTest All the main test classes (TestSuite and TestRunner) are on the test.* namespace. My project consists of various .fla files, one for each of the application's views (forms). I find fla's easier for making complex design-oriented layouts and sometimes animations. I don't insert any code on the fla file at all. Everything is coded on external AS2 classes. It wasn't also clear on how should I handle MovieClip instantiation on the test swf when this MovieClip relies on assets that are not present on the test swf's library. Thanks a lot for the help! Marcelo. On 12/29/06, Luke Bayes <lb...@gm...> wrote: > > Hey Marcelo, > > There are a couple of issues you're talking about here, I'm going to > restate them a little differently, please let me know if this is inaccurate. > > 1) Should I ever write a unit test for a visual entity? > Yes. There are definitely times when views have code. Even using MVC, the > view is responsible for some work and unit testing can verify that this work > is being done as expected. > > 2) How do I structure an application for unit testing? > Ali and I spent a considerable amount of time thinking about this problem, > and after quite a bit of trial and error, we realized that one of the most > important aspects to testing is that the environment your test harness > operates in should be as nearly identical to your production environment as > possible. This includes library assets, frameworks, etc... For example, > Macromedia's components manipulate some core object prototypes, add > functions to _global and place assets on _root in a very high level which > affects our ability to use _root.getNextHighestDepth(). IF we are using > components in our application, but fail to load that library into our test > swf, we will see behaviors in production that are very different from those > that we find in our tests. > > We generally try to avoid using a fla file if at all possible, but if we > are forced to use a .fla file for a project, the most important thing that > we do, is avoid doing any real work on the main timeline. If we have some > animation or some frame-based work that needs done, we put it into a > MovieClip. The main timeline of our .fla files generally has one line of > ActionScript. This line is usually switched from running our application > main function to running our test suite main function. This has the added > benefit of allowing us to point MTASC at either of these main functions and > simply swallow the MMC-compiled swf file. > > // SomeApplication.main(); > SomeApplicationRunner.main(); > > I hope that helps. > > > Luke Bayes > www.asunit.org > > > On 12/29/06, Marcelo de Moraes Serpa wrote: > > > > 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. > > > > > > ------------------------------------------------------------------------- > 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 > > > |
|
From: Luke B. <lb...@gm...> - 2006-12-29 23:12:24
|
Hey Marcelo, We definitely don't ship test code in our production swf files, but we do make sure that everything our production code has access to, is available in our test harness. Regardless of how you physically segment test classes from production code, the compiler will only include classes that are referenced one way or another from the main class (MTASC), the main timeline, or exported symbols (FLA). test cases point at production code, but production code never references test cases. We have seen projects built with the test classes alongside the production classes, test packages inside production packages and like you, have settled on the mirrored test package approach. Basically, it doesn't matter where the test classes are as long as nothing from your production compilation references them. In environments where we have to use a fla file, we use authoring to compile it once, then tell MTASC to use the resulting swf file as 'input'. When you do this, mtasc has access to all those visual assets by their linkage ids - forms and animations and whatnot. I also (quite handily) clobbers all ActionScript classes and replaces them with bytecode from it's compilation. This is a rather simple compiler flag available in MTASC. This process tends to work pretty well since we generally modify the code much more frequently than the visual asset fla. I wouldn't recommend creating multiple, separate fla files for each different form as this can make sharing assets and clean compilation much more complicated. When you say, "I don't insert any code on the fla file at all. Everything is coded on external AS2 classes", of course we don't write any ActionScript in the authoring tool, but we do associate ActionScript 2 classes with symbols in the fla library using the symbol properties dialog. This generally seems to work fine - even when post-compiling using MTASC. But the point is that we wind up with a fla/swf file that is compiled with MMC (Authoring) - then use MTASC to build the deployed and test harness SWF files. If we were going to try building something modular that could load separate content swfs as needed, I suspect we would use a similar process, using MTASC exclude directives to make the subsequent modular swfs... As far as MovieClip instantiation that relies on symbols that aren't available in the test harness, I would argue that a test swf that doesn't include everything that exists in the production swf is not thoroughly testing your production functionality. Does that help? Thanks, Luke Bayes www.asunit.org On 12/29/06, Marcelo de Moraes Serpa wrote: > > This line is usually switched from running our application main function > > to running our test suite main function > > > I couldn't really understand, Luke. The way I'm doing right now is having > a test swf and that is all. The way you put it, seems like you mix test code > with production code, is that right? > > Let me explain better how I've set up my unit testing workflow: > > I'm using AS2ANT unittest task. So, I compile the TestRunner into a swf > file and run it before proceeding with the rest of the build. I have two > identical project trees - one for the production source files and one for > theses classes' test classes, like this: > > * com.cconline.views.IndexView > * tests.com.cconline.views.IndexViewTest > > All the main test classes (TestSuite and TestRunner) are on the test.* > namespace. > > My project consists of various .fla files, one for each of the > application's views (forms). I find fla's easier for making complex > design-oriented layouts and sometimes animations. I don't insert any code on > the fla file at all. Everything is coded on external AS2 classes. > > It wasn't also clear on how should I handle MovieClip instantiation on the > test swf when this MovieClip relies on assets that are not present on the > test swf's library. > > Thanks a lot for the help! > > Marcelo. > > On 12/29/06, Luke Bayes <lb...@gm...> wrote: > > > > Hey Marcelo, > > > > There are a couple of issues you're talking about here, I'm going to > > restate them a little differently, please let me know if this is inaccurate. > > > > 1) Should I ever write a unit test for a visual entity? > > Yes. There are definitely times when views have code. Even using MVC, > > the view is responsible for some work and unit testing can verify that this > > work is being done as expected. > > > > 2) How do I structure an application for unit testing? > > Ali and I spent a considerable amount of time thinking about this > > problem, and after quite a bit of trial and error, we realized that one of > > the most important aspects to testing is that the environment your test > > harness operates in should be as nearly identical to your production > > environment as possible. This includes library assets, frameworks, etc... > > For example, Macromedia's components manipulate some core object prototypes, > > add functions to _global and place assets on _root in a very high level > > which affects our ability to use _root.getNextHighestDepth(). IF we are > > using components in our application, but fail to load that library into our > > test swf, we will see behaviors in production that are very different from > > those that we find in our tests. > > > > We generally try to avoid using a fla file if at all possible, but if we > > are forced to use a .fla file for a project, the most important thing that > > we do, is avoid doing any real work on the main timeline. If we have some > > animation or some frame-based work that needs done, we put it into a > > MovieClip. The main timeline of our .fla files generally has one line of > > ActionScript. This line is usually switched from running our application > > main function to running our test suite main function. This has the added > > benefit of allowing us to point MTASC at either of these main functions and > > simply swallow the MMC-compiled swf file. > > > > // SomeApplication.main(); > > SomeApplicationRunner.main(); > > > > I hope that helps. > > > > > > Luke Bayes > > www.asunit.org > > > > > > On 12/29/06, Marcelo de Moraes Serpa wrote: > > > > > > 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. > > > > > > > > > > > > ------------------------------------------------------------------------- > > 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 > > > |
|
From: Marcelo de M. S. <cel...@gm...> - 2006-12-30 00:31:56
|
Hi Luke, Does that help? > A lot! Thank you very much for taking your time to help me. Marcelo. On 12/29/06, Luke Bayes <lb...@gm...> wrote: > > Hey Marcelo, > > We definitely don't ship test code in our production swf files, but we do > make sure that everything our production code has access to, is available in > our test harness. Regardless of how you physically segment test classes from > production code, the compiler will only include classes that are referenced > one way or another from the main class (MTASC), the main timeline, or > exported symbols (FLA). test cases point at production code, but production > code never references test cases. We have seen projects built with the test > classes alongside the production classes, test packages inside production > packages and like you, have settled on the mirrored test package approach. > Basically, it doesn't matter where the test classes are as long as nothing > from your production compilation references them. > > In environments where we have to use a fla file, we use authoring to > compile it once, then tell MTASC to use the resulting swf file as 'input'. > When you do this, mtasc has access to all those visual assets by their > linkage ids - forms and animations and whatnot. I also (quite handily) > clobbers all ActionScript classes and replaces them with bytecode from it's > compilation. This is a rather simple compiler flag available in MTASC. > > This process tends to work pretty well since we generally modify the code > much more frequently than the visual asset fla. I wouldn't recommend > creating multiple, separate fla files for each different form as this can > make sharing assets and clean compilation much more complicated. > > When you say, "I don't insert any code on the fla file at all. Everything > is coded on external AS2 classes", of course we don't write any ActionScript > in the authoring tool, but we do associate ActionScript 2 classes with > symbols in the fla library using the symbol properties dialog. This > generally seems to work fine - even when post-compiling using MTASC. But the > point is that we wind up with a fla/swf file that is compiled with MMC > (Authoring) - then use MTASC to build the deployed and test harness SWF > files. If we were going to try building something modular that could load > separate content swfs as needed, I suspect we would use a similar process, > using MTASC exclude directives to make the subsequent modular swfs... > > As far as MovieClip instantiation that relies on symbols that aren't > available in the test harness, I would argue that a test swf that doesn't > include everything that exists in the production swf is not thoroughly > testing your production functionality. > > Does that help? > > > Thanks, > > > Luke Bayes > www.asunit.org > > > > On 12/29/06, Marcelo de Moraes Serpa wrote: > > > > This line is usually switched from running our application main function > > > to running our test suite main function > > > > > > I couldn't really understand, Luke. The way I'm doing right now is > > having a test swf and that is all. The way you put it, seems like you mix > > test code with production code, is that right? > > > > Let me explain better how I've set up my unit testing workflow: > > > > I'm using AS2ANT unittest task. So, I compile the TestRunner into a swf > > file and run it before proceeding with the rest of the build. I have two > > identical project trees - one for the production source files and one for > > theses classes' test classes, like this: > > > > * com.cconline.views.IndexView > > * tests.com.cconline.views.IndexViewTest > > > > All the main test classes (TestSuite and TestRunner) are on the test.* > > namespace. > > > > My project consists of various .fla files, one for each of the > > application's views (forms). I find fla's easier for making complex > > design-oriented layouts and sometimes animations. I don't insert any code on > > the fla file at all. Everything is coded on external AS2 classes. > > > > It wasn't also clear on how should I handle MovieClip instantiation on > > the test swf when this MovieClip relies on assets that are not present on > > the test swf's library. > > > > Thanks a lot for the help! > > > > Marcelo. > > > > On 12/29/06, Luke Bayes < lb...@gm...> wrote: > > > > > > Hey Marcelo, > > > > > > There are a couple of issues you're talking about here, I'm going to > > > restate them a little differently, please let me know if this is inaccurate. > > > > > > 1) Should I ever write a unit test for a visual entity? > > > Yes. There are definitely times when views have code. Even using MVC, > > > the view is responsible for some work and unit testing can verify that this > > > work is being done as expected. > > > > > > 2) How do I structure an application for unit testing? > > > Ali and I spent a considerable amount of time thinking about this > > > problem, and after quite a bit of trial and error, we realized that one of > > > the most important aspects to testing is that the environment your test > > > harness operates in should be as nearly identical to your production > > > environment as possible. This includes library assets, frameworks, etc... > > > For example, Macromedia's components manipulate some core object prototypes, > > > add functions to _global and place assets on _root in a very high level > > > which affects our ability to use _root.getNextHighestDepth(). IF we are > > > using components in our application, but fail to load that library into our > > > test swf, we will see behaviors in production that are very different from > > > those that we find in our tests. > > > > > > We generally try to avoid using a fla file if at all possible, but if > > > we are forced to use a .fla file for a project, the most important thing > > > that we do, is avoid doing any real work on the main timeline. If we have > > > some animation or some frame-based work that needs done, we put it into a > > > MovieClip. The main timeline of our .fla files generally has one line of > > > ActionScript. This line is usually switched from running our application > > > main function to running our test suite main function. This has the added > > > benefit of allowing us to point MTASC at either of these main functions and > > > simply swallow the MMC-compiled swf file. > > > > > > // SomeApplication.main(); > > > SomeApplicationRunner.main(); > > > > > > I hope that helps. > > > > > > > > > Luke Bayes > > > www.asunit.org > > > > > > > > > On 12/29/06, Marcelo de Moraes Serpa wrote: > > > > > > > > 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. > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------- > > > 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 > > > > > > > > ------------------------------------------------------------------------- > 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 > > > |