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

Re: [Asunit-users] Actionscript 2 Private Member Testing

[Holmes, J. <Jas...@ga...>]

I do this all the time while developing new functionality.  Writing test
cases is pretty much the only way for me to be sure that my method is
doing what I want it to do.  So I create a Mock class that publishes
those methods that I'm writing.

=20

However, it sounds like you're testing functionality that has already
been written.  In that case I'm with Luke and question your reasons for
doing so.  It sounds like you should just be testing your public
functionality.

=20

Also, it's been a few months since I've touched AS, but last I remember
you can't override private methods. They have to be protected at a
minimum.

=20

Jason Holmes

jas...@ga...

________________________________

From: asu...@li...
[mailto:asu...@li...] On Behalf Of Luke
Bayes
Sent: Tuesday, August 21, 2007 7:55 PM
To: Mailing List for the users of AsUnit
Subject: Re: [Asunit-users] Actionscript 2 Private Member Testing

=20

Hey Nathan,

This is a great question. There are probably quite a few different
answers and I'd love to hear what other folks have to say about it.

In general, when I find myself trying to write a unit test against some
private functionality, I consider that a code smell. It usually means
that I haven't really thought through this particular interface well
enough. Unit tests are usually intended to verify the public facing
functionality of feature.=20

With that said, there do arise some situations where it's necessary -
even if just temporarily - and in those cases, you're on the right track
(in my opinion). I would just extend the class under test and expose the
private members via helper functions.=20

As I wrote that last sentence it occurred to me that it really might be
bad advice. If you have unit tests that interact with the private
members of a class, your class becomes much more difficult to change,
and you're probably testing things on a more granular scale than need
be. Additionally, one should be able to modify (and verify) the state of
a class completely through it's public interfaces.=20

I just did a quick search on Google with "how to write good unit tests"
and came up with a handful of helpful articles. It would probably be
worth it to at least skim some articles on the subject before you go too
much further.=20

I hope that helps, and again, I'd love to hear what others on the list
have to say about this subject!


Thanks,


Luke Bayes
http://www.asserttrue.com=20


-------------------------=20
This e-mail and any attachments may contain confidential material for the s=
ole use of the intended recipient.  If you are not the intended recipient, =
please be aware that any disclosure, copying, distribution or use of this e=
-mail or any attachment is prohibited.  If you have received this e-mail in=
 error, please contact the sender and delete all copies.=20
Thank you for your cooperation=20

Re: [Asunit-users] Actionscript 2 Private Member Testing

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

Hey Nathan,

This is a great question. There are probably quite a few different answers
and I'd love to hear what other folks have to say about it.

In general, when I find myself trying to write a unit test against some
private functionality, I consider that a code smell. It usually means that I
haven't really thought through this particular interface well enough. Unit
tests are usually intended to verify the public facing functionality of
feature.

With that said, there do arise some situations where it's necessary - even
if just temporarily - and in those cases, you're on the right track (in my
opinion). I would just extend the class under test and expose the private
members via helper functions.

As I wrote that last sentence it occurred to me that it really might be bad
advice. If you have unit tests that interact with the private members of a
class, your class becomes much more difficult to change, and you're probably
testing things on a more granular scale than need be. Additionally, one
should be able to modify (and verify) the state of a class completely
through it's public interfaces.

I just did a quick search on Google with "how to write good unit tests" and
came up with a handful of helpful articles. It would probably be worth it to
at least skim some articles on the subject before you go too much further.

I hope that helps, and again, I'd love to hear what others on the list have
to say about this subject!


Thanks,


Luke Bayes
http://www.asserttrue.com

[Asunit-users] Actionscript 2 Private Member Testing

[Nathan F. <na...@gm...>]

Hello,

  I'm just starting to use asunit for testing ActionScript.  I have
legacy code with private members I would like to test.  What is the
best approach for testing them? Should I create a new test class that
extends the class to be tested or is there a way I can use reflection,
property enumeration, etc?  Any suggestions would be appreciated.

Regards,

  Nathan

[Asunit-users] (no subject)

[Jonathan M. <mar...@gm...>]

Hello,

I wrote up a small instructional post on how to run tests using  
Actionscript 3. It's an update of Tim Beynart's article

http://marstonstudio.com/index.php/2007/07/28/asunit-testing-with- 
flash-cs3-and-actionscript-3/

Any feedback and suggestions on improving the howto are welcome. If  
the group finds this article useful, maybe the asunit page could link  
to it?
I plan to write a follow up article on using asunit asynchronous  
tests to monitor a remote service, such as a rest xml service.

Thanks for the great testing framework,


Jonathan Marston

Marston Development Studio LLC
email:	jo...@ma...
phone:	(978) 758-7444
im:		marstonstudio	(gtalk/yahoo/aol)
blog:	marstonstudio.com

Re: [Asunit-users] ASUnit Docs

[Michael B. <mic...@gm...>]

Hey, you're welcome. Glad to see you could use them =)
I wasn't the one who wrote all that commentary, but it definitely made the
task a lot easier!

-Michael Baird
http://esria.com

On 7/14/07, Luke Bayes <lb...@pa...> wrote:
>
> Hey Michael,
>
> Thanks for packaging those up!
>
> I have posted the asdocs to the website at:
>
> http://www.asunit.org/#learnMore
>
> and:
>
> http://www.asunit.org/docs/asunit3/
>
> Unfortunately, I can't seem to remember who spent all that time commenting
> the code! If you're the one that did all this work, please let me know and
> I'll update the website with your name and url.
>
> Also, Michael, if you have a url you'd like us to link to, please let me
> know.
>
> If anyone wants to do the same thing with the AS 2 docs, just send me a
> zip archive and I'll be sure to post it.
>
>
> Thanks,
>
>
> Luke Bayes
> http://www.asunit.org
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Asunit-users mailing list
> Asu...@li...
> https://lists.sourceforge.net/lists/listinfo/asunit-users
>
>

[Asunit-users] Test Driven Pathfinding in ActionScript 3

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

If you know anyone who is into building Flash Games or if you just know
someone looking for a practical example on how to Test Drive AS3 with
AsUnit, please send them this link:
http://geekswithblogs.net/rstackhouse/archive/2007/07/16/113967.aspx.

Test Driven Design is a rather recently popularized way of coding in AS3 (or
any language) that can produce dependable, predictable results  (please
forgive me if I am preaching to the choir).  TDD shifts the focus in
development from "just writing some code" to "making sure code works from
the very beginning".  TDD also makes it very easy to approach a problem that
you may not be comfortable with, and may not know how to approach otherwise.
Beyond this, TDD usually makes for very clean code and code that is
immensely more maintainable.  If you are a TDD practitioner and you see me
saying something not quite in line with your thinking on TDD, please call me
on it.  I am throwing this out there to help folks learn about AS3, TDD, and
Flash Game Development and hopefully to learn from them.

Thanks and Enjoy!

Robert Stackhouse

Re: [Asunit-users] ASUnit Docs

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

Hey Michael,

Thanks for packaging those up!

I have posted the asdocs to the website at:

http://www.asunit.org/#learnMore

and:

http://www.asunit.org/docs/asunit3/

Unfortunately, I can't seem to remember who spent all that time commenting
the code! If you're the one that did all this work, please let me know and
I'll update the website with your name and url.

Also, Michael, if you have a url you'd like us to link to, please let me
know.

If anyone wants to do the same thing with the AS 2 docs, just send me a zip
archive and I'll be sure to post it.


Thanks,


Luke Bayes
http://www.asunit.org

Re: [Asunit-users] Anyone got the XUL runner working with Vista?

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

OUCH!

That's a bummer... I have to confess that Vista pushed me (kicking and
screaming) over to the OS X camp. OK, that's not entirely true, it was
really a combination of Vista's genuine security features, Quicksilver, and
primarily the ability to run many operating systems on one machine from Boot
Camp or Parallels.

Regardless of my personal reasons, I would really like that XUL UI to
support Vista, anyone interested in contributing?

One thing that may or may not help is our latest build of
AsProject<http://www.asserttrue.com/articles/2007/04/04/introducing-asproject>,
now called Sprouts <http://code.google.com/p/projectsprouts/>. It's
definitely where are energy is going these days and it does provide most of
the features found in the XUL UI, but it's certainly not very mature and
does a lot more, in some ways less (for the time being), than what XUL UI
was designed to do.


Thanks,

Luke Bayes
http://www.asserttrue.com


I just got a new laptop the other day.  I downloaded and set up the XUL
> runner.  I tried to launch it, but nada!
>
> Anybody got any ideas?
>

[Asunit-users] Anyone got the XUL runner working with Vista?

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

I just got a new laptop the other day.  I downloaded and set up the XUL
runner.  I tried to launch it, but nada!

Anybody got any ideas?

Re: [Asunit-users] Assert.as

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

Thanks Brad,

I updated the source in the AS 3 build as follows:

/**
 * Asserts that two objects do not refer to the same object. If they do,
 * an AssertionFailedError is thrown with the given message.
 */
static public function assertNotSame(...args:Array):void {


Does that look right?


Thanks,


Luke

[Asunit-users] Assert.as

[Brad B. <bra...@al...>]

Minor documentation glitch.


     /**
         * Asserts that two objects refer to the same object. If they are
not
         * an AssertionFailedError is thrown with the given message.
         */
        static public function assertSame(...args:Array):void

     /**
          * Asserts that two objects refer to the same object. If they are
not
          * an AssertionFailedError is thrown with the given message.
          */
        static public function assertNotSame(...args:Array):void

Re: [Asunit-users] Wanna Give Some Back?

[M D. <hea...@gm...>]

you Luke,
Why not let me help you set up a pledgie.com campaign. We already have
a vibrant OS community. I also think you'll have more luck with
donations considering that Pledige helps you engender more of a
community context around the act of giving.

http://www.pledgie.com

Let me know if you like the idea and if I can help out.

Later,
Mark

On 5/8/07, Luke Bayes <lb...@pa...> wrote:
> Hey Folks,
>
> This is a public call for contributions.
>
> Ali and I implemented asynchronous test methods in the ActionScript3 build
> of AsUnit last year sometime and we've been 'meaning' to get this feature
> added to the ActionScript 2.5 build. As it turns out, we've been effectively
> distracted with AsProject and Ali and I both are spending the rest of our
> time trying to build a profitable consulting and product business.
>
> With all that's going on, I wanted to check in with those AS 2 developers
> out there that might feel this is an important feature and see if anyone
> would be interested in back-porting the AS3 implementation to the AS2.5
> branch.
>
> Like any open-source project, we can't offer you money or anything like
> that, but we can offer you our (and the community's) enduring gratitude and
> some public recognition. :-)
>
> If you're interested in helping out the community with this effort, please
> send me some contact info off list so we can connect via Skype or on the
> phone. There are some details surrounding this implementation that could be
> kind of confusing and there are also some new-ish features that we'd like to
> consider.
>
>
> Thanks!
>
>
> Luke Bayes
> www.asunit.org
>
>
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Asunit-users mailing list
> Asu...@li...
> https://lists.sourceforge.net/lists/listinfo/asunit-users
>
>


-- 
--------------------------------------------------------------------
http://www.pledgie.com/  -Helping You Help Others

[Asunit-users] Wanna Give Some Back?

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

Hey Folks,

This is a public call for contributions.

Ali and I implemented asynchronous test methods in the ActionScript3 build
of AsUnit last year sometime and we've been 'meaning' to get this feature
added to the ActionScript 2.5 build. As it turns out, we've been effectively
distracted with AsProject and Ali and I both are spending the rest of our
time trying to build a profitable consulting and product business.

With all that's going on, I wanted to check in with those AS 2 developers
out there that might feel this is an important feature and see if anyone
would be interested in back-porting the AS3 implementation to the AS2.5branch.

Like any open-source project, we can't offer you money or anything like
that, but we can offer you our (and the community's) enduring gratitude and
some public recognition. :-)

If you're interested in helping out the community with this effort, please
send me some contact info off list so we can connect via Skype or on the
phone. There are some details surrounding this implementation that could be
kind of confusing and there are also some new-ish features that we'd like to
consider.


Thanks!


Luke Bayes
www.asunit.org

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

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] XUL UI

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

Hey Robert,

I really appreciate your reply and apologize for the misunderstanding. I
think I've been working a bit too much lately!

Please let us know when you post something or get ready to dig into the XUL
stuff.


Thanks,


Luke Bayes
www.asunit.org

Re: [Asunit-users] XUL UI

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

Luke,  my comment was not meant to be offensive or disrespectful and was not
aimed at ASUnit, it was instead aimed merely at a way of working (as defined
in your #2, which you and Ali seemed to have moved away from anyway).  I
would like to contribute to ASUnit if I can find the time over the summer.
I think that ASUnit is a huge asset to the community.  I think right now I
could probably contribute best by blundering along and figuring ASUnit out
on my own by experimenting and annoying good people such as yourself with
the occasional question, and then commenting about my adventures in ASUnit
on a blog, wiki, etc.

Additionally, my comments were primarily intended to be inquisitive in
nature to demonstrate my own ignorance of ASUnit and how it is intended to
be used.  I can see your arguments for #1 and grant you that you have a
point there.  I will probably proceed as in #3 for the forseeable future,
and may at some-point decide to grab the source for the XUL UI as you
suggested and try to add a way to support my own way of working without
taking away from the other two.  I am a .NET guy like I said, and in alot of
open-source .NET projects the unit tests do ship with the source code
(notably Jayrock and Monorail).  I personally find a lot of value in having
access to tests in source code so that I can look at how the architects of a
thing wanted it to work.  This is part of how I figured out how to use
Jayrock and Monorail (along with pestering the authors of those applications
on mailing lists and forums).

In summary,  I mean only to further my own understanding of ASUnit and that
of others as well, not to insult.  My sincerest apologies.

Thanks for all the good work, and here's to hoping you and others like you
keep doing so.

Robert

On 4/11/07, Luke Bayes <lb...@pa...> wrote:
>
> Hey Robert,
>
> When we started looking into test driven development, we saw three primary
> approaches for project layouts in the wild. Ali and I spent quite a bit of
> time reading and evaluating the benefits and drawbacks of each approach. At
> the end of our evaluation, we landed on using approach #1, and supporting
> approach #2. Even though we saw a small handful of people debating in
> various (other language) forums for approach #3, this is the first we've
> heard anyone expecting AsUnit tools to support it.
>
> Following are the project layout approaches that we saw in the wild:
>
> 1) Sibling, Identical test and source paths:
>
> This is the approach that we use and recommend. This approach usually
> involves a sibling test and source path that have identical structure, but
> the location of these two paths is irrelevant, they just need the same
> internal structure.
>
> A source class with a fully-qualified name like: foo.utils.MathUtil will
> be located at: src/foo/utils/MathUtil.as. There will be a similarly named
> test case at: test/foo/utils/MathUtilTest.as. From the perspective of the
> compiler, these two classes are actually in the same package and can
> therefore access internal or 'package' scoped values. We can also easily
> export the physical source files without the test harness when that's
> desirable. This approach has the added benefits of making it clear when test
> coverage is truly missing (an empty or missing test package), and keeping
> our test and source package relatively uncluttered.
>
> 2) Tests next to the Source:
>
> This is when you will see test cases sitting right next to source files in
> the standard class path. We started working with this approach and found
> that our packages became unwieldy and cluttered. We also had problems
> distributing sources without the tests. This approach also made it hard to
> see visually how our coverage was doing.
>
> 3) Embedded Test Packages:
>
> This is what you appear to be using. Where any package within the source
> path may include a test package with relevant tests. This approach has some
> significant drawbacks because your test cases are now being executed in a
> different scope from the classes that they're testing. This means that (in
> AS 3 at least) they cannot access 'internal' scoped values and declarations.
> For this reason, most of the Java people that we spoke with moved away from
> this approach. We work hard to make AsUnit as consistent as possible across
> the different implementations of ActionScript, so for us, a limiting factor
> in one version can often have impacts in others.
>
> Similar to #2, this approach makes it difficult to ship source code
> without the test harness. In considering this approach and trying it out, we
> also found ourselves getting burnt dealing with import statements.
> Basically, test cases tend to need many more import statements than they do
> in the other two approaches and this makes refactoring even more painful
> than it already is in ActionScript.
>
> So - If you'd like to structure a project using that 3rd approach, there
> is definitely nothing stopping you, and AsUnit should work just fine, but
> I'm not expecting to build any additional tools that support this layout
> anytime soon.
>
> I would also like to ask you to remember that you're working with tools
> and code that Ali Mills and I have spent countless hours building,
> debugging, promoting, supporting and distributing over the past 3 years,
> without receiving a dime of compensation. We contribute our time and energy
> to this project because we believe that it's important for the community.
>
> While bug reports, feature requests and questions are welcomed here,
> drawing an incorrect conclusion ("tests and source have to be in the same
> folder?" - Your source and test paths can be anywhere you want.) and
> responding with "Yuck!", is a little offensive.
>
> If you feel something wasn't designed with your very specific and
> particular interests in mind, that's because it probably wasn't. We built
> these tools to work for us first and foremost, if other people can get some
> value out of them - great, Thousands of people do! But if some people can't,
> well - that's OK too.
>
> Finally, please don't forget it is open source, if you'd like to see the
> XUL UI get a new feature, please feel free to download the sources and
> submit a patch with your new feature working.
>
>
> 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] XUL UI

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

Hey Robert,

When we started looking into test driven development, we saw three primary
approaches for project layouts in the wild. Ali and I spent quite a bit of
time reading and evaluating the benefits and drawbacks of each approach. At
the end of our evaluation, we landed on using approach #1, and supporting
approach #2. Even though we saw a small handful of people debating in
various (other language) forums for approach #3, this is the first we've
heard anyone expecting AsUnit tools to support it.

Following are the project layout approaches that we saw in the wild:

1) Sibling, Identical test and source paths:

This is the approach that we use and recommend. This approach usually
involves a sibling test and source path that have identical structure, but
the location of these two paths is irrelevant, they just need the same
internal structure.

A source class with a fully-qualified name like: foo.utils.MathUtil will be
located at: src/foo/utils/MathUtil.as. There will be a similarly named test
case at: test/foo/utils/MathUtilTest.as. From the perspective of the
compiler, these two classes are actually in the same package and can
therefore access internal or 'package' scoped values. We can also easily
export the physical source files without the test harness when that's
desirable. This approach has the added benefits of making it clear when test
coverage is truly missing (an empty or missing test package), and keeping
our test and source package relatively uncluttered.

2) Tests next to the Source:

This is when you will see test cases sitting right next to source files in
the standard class path. We started working with this approach and found
that our packages became unwieldy and cluttered. We also had problems
distributing sources without the tests. This approach also made it hard to
see visually how our coverage was doing.

3) Embedded Test Packages:

This is what you appear to be using. Where any package within the source
path may include a test package with relevant tests. This approach has some
significant drawbacks because your test cases are now being executed in a
different scope from the classes that they're testing. This means that (in
AS 3 at least) they cannot access 'internal' scoped values and declarations.
For this reason, most of the Java people that we spoke with moved away from
this approach. We work hard to make AsUnit as consistent as possible across
the different implementations of ActionScript, so for us, a limiting factor
in one version can often have impacts in others.

Similar to #2, this approach makes it difficult to ship source code without
the test harness. In considering this approach and trying it out, we also
found ourselves getting burnt dealing with import statements. Basically,
test cases tend to need many more import statements than they do in the
other two approaches and this makes refactoring even more painful than it
already is in ActionScript.

So - If you'd like to structure a project using that 3rd approach, there is
definitely nothing stopping you, and AsUnit should work just fine, but I'm
not expecting to build any additional tools that support this layout anytime
soon.

I would also like to ask you to remember that you're working with tools and
code that Ali Mills and I have spent countless hours building, debugging,
promoting, supporting and distributing over the past 3 years, without
receiving a dime of compensation. We contribute our time and energy to this
project because we believe that it's important for the community.

While bug reports, feature requests and questions are welcomed here, drawing
an incorrect conclusion ("tests and source have to be in the same folder?" -
Your source and test paths can be anywhere you want.) and responding with
"Yuck!", is a little offensive.

If you feel something wasn't designed with your very specific and particular
interests in mind, that's because it probably wasn't. We built these tools
to work for us first and foremost, if other people can get some value out of
them - great, Thousands of people do! But if some people can't, well -
that's OK too.

Finally, please don't forget it is open source, if you'd like to see the XUL
UI get a new feature, please feel free to download the sources and submit a
patch with your new feature working.


Thanks,


Luke Bayes
www.asunit.org

Re: [Asunit-users] XUL UI

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

Ok.  There is one problem with this.  The XUL UI creates all of the folders
in the fully qualified name.  So this limits you to defining the source and
the test path as the same thing and they have to be defined as the parent
directory for your library.  There is no option for "TestName" either.  So
your tests and source have to be in the same folder? Yuck.  But I have a
folder named tests in my directory structure, so something weird happens.

Say my package name is com.somesite, and I have a folder
./com/somesite/tests.  Then I do as you suggest, clicking the Create button
and clicking "No" to avoid overwriting my class.  But then I wind up with
./com/somesite/tests/com/somesite/MyClassTest.as.  This is totally
unexpected.  Is this how the system is supposed to work?

Thanks,

Robert

On 4/10/07, Luke Bayes <lb...@pa...> wrote:
>
>
> I have an already existing library that I want to start adding tests to.
> > I can't seem to make the ASUnit XUL UI pick up on the package names in my
> > library.  Is there some way to do this that I missed?
> >
>
> The XUL UI is a bit confusing when it comes to creating TestCases for
> existing classes. You'll want to get it set up with the source path and test
> path, and then (strangely), tell it to create a class using a fully
> qualified *existing* class name. You should be prompted before it overwrites
> the file. At this point, you can choose to ignore the class-creation step,
> while allowing the TestCase to be created properly.
>
> I have used this feature many times and fully trust it, but just for good
> measure, you should be certain that your code is checked into version
> control and up to date.
>
> Does that answer your question?
>
>
> 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] XUL UI

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

> I have an already existing library that I want to start adding tests to.
> I can't seem to make the ASUnit XUL UI pick up on the package names in my
> library.  Is there some way to do this that I missed?
>

The XUL UI is a bit confusing when it comes to creating TestCases for
existing classes. You'll want to get it set up with the source path and test
path, and then (strangely), tell it to create a class using a fully
qualified *existing* class name. You should be prompted before it overwrites
the file. At this point, you can choose to ignore the class-creation step,
while allowing the TestCase to be created properly.

I have used this feature many times and fully trust it, but just for good
measure, you should be certain that your code is checked into version
control and up to date.

Does that answer your question?


Thanks,

Luke Bayes
www.asunit.org

[Asunit-users] XUL UI

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

I have an already existing library that I want to start adding tests to.  I
can't seem to make the ASUnit XUL UI pick up on the package names in my
library.  Is there some way to do this that I missed?

Thanks,

Robert

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 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...@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...>]

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
>
>