asunit-users

[Asunit-users] XUL UI

[Nigel H. <nig...@gm...>]

Hi,

The idea of test driven Actionscript development sounds 'very' interesting.
But although this may sound harsh, there is nowhere near enough info on
getting AsUnit and XUL set up and running. I just do not have the time to
mess about bouncing round a number of sites working out how to get this
thing going.

Do you have any plans to produce a tutorial so any idiot like me can get up
and running. And I do not mean a blog posting pointing to a few sites where
you may or may not be able to work things out. I mean a one stop shop. A
detailed tutorial that shows you how to get XUL and AsUnit set up and then
have a simple test written and running.

It would also be interesting to know what cannot be unit tested e.g.
movieclip creation? Or have some generic tests for common code or
situations. This kind of thing would really help people get going.

Thanks,
-Nigel

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

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

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

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,

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

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

Hey Nigel,

I definitely appreciate your feedback and I'm sorry that you've found it so
frustrating. The answer to all of your questions is an emphatic YES.

We do plan on dramatically simplifying the process required to get up and
running. Unfortunately, our time is being pulled in many directions right
now. I have spent more than a few hours (40+) trying to build an installer
for Firefox so that the XUL UI could be run as a simple extension, but alas=
,
for all my effort I have been unsuccessful. Once we have that going, we wil=
l
be a long way toward the goal.

As far as tutorials go, YES. We would love to get some tutorials and
examples posted that make this process much easier. Again, this is a
resource allocation issue...

I hope to have more solid info by the end of the year, and as always, we ar=
e
hoping to get some help from the community! This is an open-source project
after all...

If you're looking for more general information on Test-Driven development,
you can find some really great (and applicable) tutorials at
www.juint.org<http://www.juint.org>
.



Thanks,


Luke Bayes
www.asunit.org <http://www.asunit.org>

Re: [Asunit-users] Re: XUL UI

[jeremy lu <wa...@gm...>]

well, acutally I don't use this feature too often either, just curious how
close it is to JUnit :P

there's one scenerio I can come up with, during a test-driven process, one
might write several tests first then started implement the real class, he
might want to test one method a time, so he can put the method in question
inside suite() then run it.

but surely this could be done just by commenting out those test methods not
needed :-)

btw, I wrote a simple tutorial in chinese here :
http://ria.richtechmedia.com/?p=3D296

jeremy.

On 11/15/05, Luke Bayes <lb...@gm...> wrote:
>
> Hey Jeremy,
>
> That's a great question. During the Java-to-AS3 migration, I couldn't hel=
p
> but notice that JUnit does support this. Unfortunately, we chose not to a=
dd
> this capability to the current build.
>
> I haven't really been able to come up with a good reason for this feature
> that would justify the implementation time.
>
> My understanding (and practice) has been that one should execute the
> entire fixture whenever it is technically reasonable and it seemed to me
> like this feature would allow developers (especially me) to *think* that =
all
> of my test cases were being executed when in fact only a small subset was
> actually being executed.
>
> Do you use this feature in development?
>
> What circumstances lead you to use this?
>
> Thanks,
>
>
> Luke Bayes
>
>

Re: [Asunit-users] Re: XUL UI

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

Hey Jeremy,

Thanks for contributing the tutorial! I'll get a link to it up on
asunit.org<http://asunit.org>tomorrow.

Ali and I talked about this feature today a little more, and I'm leaning
toward implementing it - I think that it really could add value to the
development process and help make it more efficient to build
incrementally.Shamefully, our current development process currently involve=
s
commenting out test methods when we're in a big Test Case... I believe that
would be precisely the use case for this feature!

Thanks so much for bringing this up!


Luke Bayes
www.asunit.org <http://www.asunit.org>

Re: [Asunit-users] Re: XUL UI

[Grant C. <gr...@dv...>]

Hi Luke,

I have not looked at these recent additions to AsUnit (too busy with 
other projects right now), but one problem I have had with AsUnit in the 
past is related to what you just said - thinking all the cases are 
passing when in fact they aren't being run.  Specifically, the issues I 
have had are related to Remoting functions which rely heavily on 
callbacks, and when something fails (perhaps on the server side) my 
callbacks may fail and the tests do not complete.

Our solution to this was to manually count the number of passing tests 
we should have and add this as a comment in the main AsUnit application, 
and to check this whenever we ran the tests (and of course increment it 
as tests were added).  But as you can imagine, this sucks.

Do you know of any Actionscript code coverage tools, or have any plans 
to implement something basic into AsUnit?  Even as simple as displaying 
how many asserts were not run would be fine - unfortunately I just can't 
think of how this would be accomplished without a pre-processing step.

Regards,
Grant Cox


Luke Bayes wrote:

> Hey Jeremy,
>
> That's a great question. During the Java-to-AS3 migration, I couldn't 
> help but notice that JUnit does support this. Unfortunately, we chose 
> not to add this capability to the current build.
>
> I haven't really been able to come up with a good reason for this 
> feature that would justify the implementation time.
>
> My understanding (and practice) has been that one should execute the 
> entire fixture whenever it is technically reasonable and it seemed to 
> me like this feature would allow developers (especially me) to *think* 
> that all of my test cases were being executed when in fact only a 
> small subset was actually being executed.
>
> Do you use this feature in development?
>
> What circumstances lead you to use this?
>
> Thanks,
>
>
> Luke Bayes
>

Re: [Asunit-users] Re: XUL UI

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

That's a really interesting problem Grant, thanks for the feedback!

I have definitely struggled with the same issue extensively. Generally, whe=
n
I find a smell that's bothering me in my test code, I go start searching
junit.org <http://junit.org> to see if some java person has had similar
issues, as it turns out with this particular problem - fortunately - we're
not alone!

The first and most important thing that you can possibly do, is stop testin=
g
your server with your client. Your client and server should each be tested
independently of the network and of each other.

There are quite a few great articles on junit.org
<http://junit.org>discussing this very topic for Java applications.
Here are a few links I
found:

Writing Networked Unit Tests:
http://www.javaworld.com/javaworld/jw-07-2002/jw-0719-networkunittest.html

Mock Objects 1:
http://www-128.ibm.com/developerworks/library/j-mocktest.html

Mock Objects 2:
http://www.onjava.com/pub/a/onjava/2004/02/11/mocks.html

JUnit.org Articles Index:
http://www.junit.org/news/article/index.htm


I hope this helps!


Thanks,


Luke Bayes
www.asunit.org <http://www.asunit.org>