What with all the holiday cheer going around (who can’t be cheerful with
a preview of 1.8 by Christmas?!?) I had to make my own little
contribution to the glee…
If you don’t know what Test::Unit is, I’ve included an explanation
further down. Before I get there, though, I want to let everyone know a
few important things about this release:
TestCase#set_up has reverted back to #setup. This will almost
assuredly break almost everyone’s tests. Sorry for the wishy-washiness,
but you can be assured it will stay#setup from now on.
You should definitely read the ChangeLog. The #setup name change is
not the only potential code breaker.
I consider this the candidate to move in to 1.8 (which move is my
next priority now that this release is off my plate). Please pound it so
that I can fix any remaining issues earlier rather than later.
I have a lot of ideas for future development… if you’re interested,
have a look at the TODO in CVS. Things haven’t stalled - rather I’ve
just finished getting married and finally have time to work on it again.
From the README:
Unit testing is making waves all over the place, largely due to the fact
that it is a core practice of XP. While XP is great, unit testing has
been around for a long time and has always been a good idea. One of the
keys to good unit testing, though, is not just writing tests, but having
tests. What’s the difference? Well, if you just write a test and throw
it away, you have no guarantee that something won’t change later which
breaks your code. If, on the other hand, you have tests (obviously you
have to write them first), and run them as often as possible, you slowly
build up a wall of things that cannot break without you immediately
knowing about it. This is when unit testing hits its peak usefulness.
Enter Test::Unit, a framework for unit testing in Ruby, helping you to
design, debug and evaluate your code by making it easy to write and have
tests for it.
What with all the holiday cheer going around (who can’t be cheerful
with a preview of 1.8 by Christmas?!?) I had to make my own little
contribution to the glee…
Thumbs up. I ran the gamut of my existing tests with no problem.
They make use of the RubyUnit compatibility layer, which I guess
isolates me from setup -vs- set_up issues, etc (wasn’t there a HUGE
thread on the relative merits of each name? ).
Running with RubyUnit natively runs roughly 2.5 times faster than with
Test::Unit’s RubyUnit compatibility layer. 20 -vs- 54 seconds under
ruby CVS. Is this a known issue? Do you think this is the
compatibility layer being inefficient, or is Test::Unit just slower?
It bothers me only slightly to know that most of the time I spend
waiting for Test::Unit to finish is time spent in Test::Unit and not
my tests. Optimization can come later.
TestCase#set_up has reverted back to #setup. This will almost
assuredly break almost everyone’s tests. Sorry for the wishy-washiness,
but you can be assured it will stay#setup from now on.
I don’t see it explicitly stated in the ChangeLog, but has
TestCase#tear_down likewise been renamed to TestCase#teardown?
TestCase#set_up has reverted back to #setup. This will almost
assuredly break almost everyone’s tests. Sorry for the wishy-washiness,
but you can be assured it will stay#setup from now on.
I don’t see it explicitly stated in the ChangeLog, but has
TestCase#tear_down likewise been renamed to TestCase#teardown?
I was just wondering the same thing…
Any reason we couldn’t keep a “set_up” alias around for backwards
compatability?
Also, the tc_adder.rb and tc_subtractor.rb examples need to be updated, then
(I think).
What with all the holiday cheer going around (who can’t be cheerful
with a preview of 1.8 by Christmas?!?) I had to make my own little
contribution to the glee…
Thumbs up. I ran the gamut of my existing tests with no
problem. They make use of the RubyUnit compatibility layer,
which I guess isolates me from setup -vs- set_up issues, etc
(wasn’t there a HUGE thread on the relative merits of each
name? ).
Yeah. I don’t want to talk about it.
Running with RubyUnit natively runs roughly 2.5 times faster
than with Test::Unit’s RubyUnit compatibility layer. 20 -vs-
54 seconds under ruby CVS. Is this a known issue? Do you
think this is the compatibility layer being inefficient, or
is Test::Unit just slower?
Probably Test::Unit being slower. I’ve never run a profiler on it, as
I’ve been more concerned with getting the API right than in making it
fast. However, it’s about time to make it fast, so I’ve added something
to the TODO regarding optimization.
It bothers me only slightly to know that most of the time I
spend waiting for Test::Unit to finish is time spent in
Test::Unit and not my tests. Optimization can come later.
Indeed. “Make it run, make it right, make it fast, in that order.” I
daily wish that all programmers would make that their mantra.
Any reason we couldn’t keep a “set_up” alias around for
backwards compatability?
I personally do not like aliasing, particularly when it is done for
backwards compatibility reasons. The interface is going to stabilize
now, particularly since we’re moving in to the standard distribution,
and it seems preferrable to have consistent code, even if it means a bit
of pain now.
Of course, you can always alias it yourself…
Also, the tc_adder.rb and tc_subtractor.rb examples need to
be updated, then (I think).
I knew I’d miss something :-/. Oh well, if it had to be anything, at
least it was the examples.
Hmm. Do you use it as a noun (in English, I mean)? Do you
hyphenate it? (The difference between “set up” and “setup”
is, of course, verb vs. noun.)
I can see where either of these might be considered correct:
“The tear-down of the system occurred without incident.”
“The teardown of the system occurred without incident.”
This, I think, would not be:
“The tear down of the system occurred without incident.”
And obviously as a verb it would HAVE to be two non-hyphenated
words.
But where English fights computer science, the former will
always be the loser. AOP people seem to use the plural
“advices” rather than “advice” or “pieces of advice.”
I don’t see it explicitly stated in the ChangeLog, but has
TestCase#tear_down likewise been renamed to TestCase#teardown?
No. Tear down is definitely two words, while setup could be one or
two. Plus the fact that tear_down is used a lot less often.
Hmm. Do you use it as a noun (in English, I mean)? Do you
hyphenate it? (The difference between “set up” and “setup”
is, of course, verb vs. noun.)
Which was, of course, debated back and forth ad nauseum on the list not
to long ago… not to mention the longstanding debate going on in my
head
Suffice it to say, the names are stabilized, and will not change again,
at least not until Test::Unit runs under Rite
But where English fights computer science, the former will
always be the loser. AOP people seem to use the plural
“advices” rather than “advice” or “pieces of advice.”
Programmers definitely use English in a very opportunistic way. My dad
regularly bemoans the fact that the geeks have taken all the words and
redefined them to mean something he doesn’t understand.
Hmm, I missed that discussion and can’t find it now.
Well, first of all:
Your software, not mine! And thanks for
doing this, by the way.
I accept that you’re not going to change
the names and I’m not flaming you.
But speaking as a nitpicker and the son of an
English teacher, emphatically a mixed blessing,
I’m always bothered by antiparallelism.
For example, suppose I had “starting” and “ending”
methods of some kind. I might name them
initiate/terminate (verbs) or initiation/termination
(nouns). But I’d never name them initiate/termination
or initiation/terminate.
But you had a verb-verb form and explicitly changed
it to noun-verb. Why? What does that buy you?
<even_further_off_topic>
I recall a radio ad for some beauty product line that
probably didn’t trip anyone’s wires but my own. It
said, “Products for your hair, your skin, and your
lifestyle.” Hmm! Subtle, maybe, but I’d consider that
antiparallel also. Surely no one smears stuff on her
lifestyle the same way she smears it on her hair and
skin.
But sometimes it’s done deliberately for a subtle
comic effect, as in the line from a poem where a woman
“made” three things: “She made a surmise, up her mind,
and a dash for the door.”
</even_further_off_topic>
Hmm, I missed that discussion and can’t find it now.
One such thread starts at ruby-talk:35787.
Well, first of all:
Your software, not mine! And thanks for
doing this, by the way.
I enjoy doing it, and even enjoy the discussions about naming. Always
makes me think, at least :-).
And I wouldn’t consider it my software… I’m simply the current
caretaker of it. The community as a whole will certainly use it a lot
more corporately than I ever will personally.
I accept that you’re not going to change
the names and I’m not flaming you.
I’m not worried about anybody flaming me. I’m always interested in
discussing design decisions, and I’m sorry if I implicated otherwise.
But speaking as a nitpicker and the son of an
English teacher, emphatically a mixed blessing,
I’m always bothered by antiparallelism.
For example, suppose I had “starting” and “ending”
methods of some kind. I might name them
initiate/terminate (verbs) or initiation/termination
(nouns). But I’d never name them initiate/termination
or initiation/terminate.
But you had a verb-verb form and explicitly changed
it to noun-verb. Why? What does that buy you?
This change was all about eliminating the underscore in setup. I decided
not to change tear_down originally, since I had some kind of mental
block that caused me to think that tear_down was always two words. I was
wrong; it can, indeed, be one word. Thus, I’m now heavily leaning
towards making it teardown, since I, too, do not like antiparallelisms.
Don’t know if this was only meant as a joke, but I too don’t like to
have setup and tear_down. To me it looks awfully asymmetric. Plus I
have to change all my tests again (having changed both set_up and
tear_down)
But as the others said: thanks a lot for the software. I’m looking
forward to Rite with the promised name change to teardown
On Sat, 21 Dec 2002 nathaniel@NOSPAMtalbott.ws wrote:
block that caused me to think that tear_down was always two words. I was
wrong; it can, indeed, be one word. Thus, I’m now heavily leaning
towards making it teardown, since I, too, do not like antiparallelisms.
Don’t know if this was only meant as a joke, but I too don’t like to
have setup and tear_down. To me it looks awfully asymmetric. Plus I
have to change all my tests again (having changed both set_up and
tear_down)
What did you think might be a joke?
And I truly am sorry about making everyone change their tests again
:-(. Maybe someone could write a little utility to change them
automatically (fully unit tested, of course ;-).
But as the others said: thanks a lot for the software. I’m looking
forward to Rite with the promised name change to teardown
You might not have to wait for Rite… while I don’t plan to change
setup, as said in my reply to Hal, I may change teardown now.
P.S. Once I get this sorted out, matz has given me the go-ahead to
commit Test::Unit to HEAD in src/ruby/lib/. Expect Test::Unit to be
standard in your Ruby distro RSN!
).
