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