From: Nathaniel Talbott <nathaniel@...>
Date: 2002-03-22T12:10:57+09:00
Subject: RE: Rubicon -> Test::Unit [long]

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?


> (including adding attr_readers for
> failures and errors to Test::Unit::TestResult),

I was thinking not too long ago that some sort of access to these would
be handy; I just haven't decided yet how to provide that access. Part of
me says just allow direct access via attr_reader, but another part wants
to do something more like providing #each_failure and #each_error
methods. I lean towards the latter because I don't really like exposing
the internal structure of the result to the outside world, and allowing
the outside world to change that structure indirectly (i.e. by getting
the arrays and then modifying them). Thoughts?


> and created a
> stand-alone BulkTestRunner which runs all the tests in all 
> the files that it is passed and produces a rubicon-style 
> summary, e.g.,

It seems (correct me if I'm wrong) that you're really
introducing/requesting two sets of functionality. One is the very cool
test run summarization that the BulkTestRunner provides. The other is
the ability to build a suite of tests automatically off of the file
system. The former I think definitely goes in to the framework as a
TestRunner, and I'm going to add it to the TODO. The latter I'm a bit
fuzzier on; I definitely see its value; I'm just not sure yet of a good
way to implement it that will support the various styles of structuring
and naming files. Also, I think it ought to live outside of the
TestRunners, as their responsibilities really begin after the suite
they're running has already been created.


I've snipped most of the code, but I did have a few questions:

<big snip>

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


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



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


Nathaniel

<:((><
+ - -
| RoleModel Software, Inc.
| EQUIP VI