"Nathaniel Talbott" <nathaniel / talbott.ws> wrote:
>
> Bil Kleb [mailto:W.L.Kleb / LaRC.NASA.Gov] wrote:
> 
> > So, apparently being too impatient for an answer, I stole the 
> > pertinent bits from rubicon, somehow(?!) modified them to work with 
> > Test::Unit
> 
> Bravo! This looks very interesting. One question I have: what were your
> thoughts/opinions on the Test::Unit API as you were digging around under
> the hood?

Nothing significant, just my usual pedantic whining:

- Documentation was a bit sparse, particularly the areas of
  basic use and overall design

- I didn't understand the need for "# :nodoc" everywhere, it
  seemed that not using the --all option for rdoc would have
  accomplished the same thing, i.e., rdoc does not document
  private methods, etc.  However, for those who want to see
  all the methods, the option is there.

- I had trouble with the indentation due to my current editor
  (emacs).  You use tabs for indentation and apparently emacs'
  default tab setting is eight, so the code was displayed in
  a very wide and hard-to-read format until I figured out what
  was going on and \M-x set-variable tab-width 1

- As I wrote in another thread, it seemed like "quiet_mode" should
  be renamed "verbose_mode", and "verbose_mode" should be enhanced.

- Not being a Java person, it took me awhile to figure out the
  directory structure. For instance, there are several directories
  named "test", but they all mean different things.

> Thoughts? [Regarding attr_reader :errors, :failures] 

I don't feel I'm qualified to voice an opinion: I merely
encountered an

 ./BulkTestRunner.rb:93:in `initialize_from': undefined method `errors' for 
 #<Test::Unit::TestResult:0x40249ea4> (NameError)

error and added the appropriate readers to preclude the
failing "test".

> It seems (correct me if I'm wrong) that you're really
> introducing/requesting two sets of functionality.

I agree.  I envisioned that something akin to bulktestrunner.rb
would reside with the original console testrunner, i.e.,

  Test::Unit::UI::Console

(although some bits might be better off in Test::Unit::Util).
This would provide the first bit functionality (running and
summarizing a bunch of tests).

I would make the user responsible for the second bit of
functionality, i.e., crafting something which bundles the tests
they want to run.  I would give the user a short example like,

 <file name="RunMobilityTests.rb">
  #!/usr/bin/env ruby
  require 'test/unit/ui/console/bulktestrunner'
  tests = Test::Unit::UI::Console::BulkTestRunner.new([],"Mobility Test Summary")
  Dir["*MT.rb"].each{|mt| tests.addFile(mt)}
  tests.run
 </file>

and let them figure out the details of how to cope with their
situation.  If a clever or standard way of doing this emerges,
then, at that point, it might be worth considering it for the
Testing framework.

For the project I'm working on, the convention of having the
tests reside in the source directory with the suffix "MT.rb"
has been very nice.  It serves to differentiate the tests
from the source code, and yet it keeps the test-code pairs
next to each other when viewing the contents of the directory
or working in XP's test-code-test-code style.  And, it allows
one to easily run one or all the tests in that directory.

However, I do not have stub classes, mock objects, test fixture
files, etc. which might quickly turn this convention into a mess
and perhaps lead one to create a separate MobilityTests directory
to house all the tests; or, IMHO, a better alternative outlined at

  http://www.c2.com/cgi/wiki?UnitTestsDefined

where one has a separate "filenameMT" directory for each source
file. Each MobilityTest directory contains a link to the actual
source file immediately above, the test code, and any trappings
the test code requires.
 
> I've snipped most of the code, but I did have a few questions:
>
> [Referring to class Results]
> >     # Objects of this class get generated from the TestResult
> >     # passed back by Test::Unit. We don't use it's class for two reasons:
> >     # 1. We de-couple better this way
> 
> Perhaps, but it does seem to duplicate a lot.

These are comments I didn't touch from Rubicon, they may
no longer apply with Test::Unit.

> >     # 2. We can't serialize the Test::Unit class, as it contains IO 
> > objects
> 
> Why did you want to serialize it, out of curiosity? Also, what IO
> objects does it contain? The only un-marshallable stuff I know of is
> Proc references, and those are irrelevant after the run is complete. If
> it's really important to be able to marshal it, I can see if it's
> possible to get Ruby to ignore those when it marshals.

Again, this comment came from Rubicon -- I don't even understand
what "marhsal" means!

> Thanks a ton for the effort/input! It will definitely make its way in to
> the Test::Unit codebase in some form or shape.

I can't take much credit, I merely mangled Rubicon's code to suit
my immediate needs...

--
Bil Kleb
NASA Langley Research Center
Hampton, Virginia, USA