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