Weirdness with ruby unit testing on mac

Ruby
1

I have a ruby project that I’ve written in a Linux environment. (Ruby
1.8.5, on Ubuntu.) I’d like to work on it on my Mac (Ruby 1.8.2, OSX
10.4) while I’m on vacation, and something weird is happening with my
tests.

The project lives in a directory ‘dbcdb’ of my $RUBYLIB; there’s a
subdirectory ‘test’, with a file ‘all.rb’ containing lines like this:

require ‘dbcdb/test/test_author_printer’
require ‘dbcdb/test/test_author_writer’
require ‘dbcdb/test/test_book_writer’

Each of those test files defines a suite.

On the Linux box, if I do

ruby -e “require ‘dbcdb/test/all’”

it runs all of them:

panini$ ruby -e “require ‘dbcdb/test/all’”
Loaded suite -e
Started
…
Finished in 0.083742 seconds.

102 tests, 384 assertions, 0 failures, 0 errors

On the Mac, though, it does this:

truffle:~ carlton$ ruby -e “require ‘dbcdb/test/all’”
Loaded suite .
Started

Finished in 0.000213 seconds.

0 tests, 0 assertions, 0 failures, 0 errors

If I try to run one of the test files, it claims to run some tests:

truffle:~ carlton$ ruby -e “require ‘dbcdb/test/test_author_printer’”
Loaded suite .
Started
…
Finished in 0.040504 seconds.

100 tests, 383 assertions, 0 failures, 0 errors

but that’s equally bizarre since test_author_printer doesn’t contain
100 tests.

What’s going on here? Is there some difference between 1.8.2 and
1.8.5 that I’m unaware of, or something weird about the Mac ruby
installation, or what? If it’s not something well-known, what’s the
best way to debug the problem?

Thanks,
David C.
[email protected]

2

On 7/14/07, David C. [email protected] wrote:

require ‘dbcdb/test/test_book_writer’
Loaded suite -e
Started
…
best way to debug the problem?

Thanks,
David C.
[email protected]

First of all, you should be doing:
ruby dbcdb/test/all.rb
Not your wacky thing with -e and require. Dunno if that will fix it,
but it is standard practice this way.

3

David C. wrote:

I have a ruby project that I’ve written in a Linux environment. (Ruby
1.8.5, on Ubuntu.) I’d like to work on it on my Mac (Ruby 1.8.2, OSX
10.4) while I’m on vacation, and something weird is happening with my
tests.

I have no idea if this would help, but standard recommendation is to go
to Ruby 1.8.6

Instructions here:

stopping after the gems install.

Although this may not make for vacation fun with no payoff.

4

On Sun, 15 Jul 2007 05:23:54 +0900, Ryan D.
[email protected] said:

On Jul 13, 2007, at 22:20 , David C. wrote:

The project lives in a directory ‘dbcdb’ of my $RUBYLIB; there’s a
subdirectory ‘test’, with a file ‘all.rb’ containing lines like this:

require ‘dbcdb/test/test_author_printer’
require ‘dbcdb/test/test_author_writer’
require ‘dbcdb/test/test_book_writer’

  1. GENERALLY: work from the project directory and refer to everything
    from there. Remove ‘dbcdb/’ from those requires.

Hmm, interesting. Wouldn’t that make my code dependent on the
directory that I’m running it from? Which I don’t care about for the
test code, but I do care about for the project code proper. (As this
probably makes clear, I don’t have a lot of Ruby experience…)

  1. ruby -w test/all.rb should work fine.

And it does, thanks!

Which gets me really confused: why would

ruby -e “require ‘dbcdb/test/all’”

do something weird but

ruby -w dbcdb/test/all.rb

do the right thing? It’s doing something with those files - it’s not
like I can type in a bogus filename. Of course, I should be doing
ruby -we instead of ruby -e: that way I get:

truffle:~/ruby/lib/ruby/site_ruby/1.8 carlton$ ruby -we “require
‘dbcdb/test/all’” 2>&1 | more
./dbcdb/test/test_author_printer.rb:8: warning: method redefined;
discarding old test_no_books
./dbcdb/test/test_author_writer.rb:8: warning: method redefined;
discarding old test_name

(a bunch of lines, one for each test suite, warning about the first
method from each suite). So at least I have some place to start
digging…

Of course, now that I have a method that works, I’m a little less
actively concerned about that mystery - as long as I’ll have a nice
vacation, the details don’t matter too much right now!

  1. find test -name *.rb – make sure cases are correct and you don’t
    have anything weird like overlapping names. OSX is by default case
    insensitive. Linux is case sensitive. By getting differing numbers of
    tests running it makes me think one of the files is being shadowed.
  1. 1.8.2 on osx is slightly broken, but only for ruby extensions. If
    this is all pure ruby, please ignore.

Thanks for the suggestions; all lowercase, pure ruby.

David C.
[email protected]

5

On Sat, 14 Jul 2007 23:23:25 +0900, “Chris C.” [email protected]
said:

On 7/14/07, David C. [email protected] wrote:

ruby -e “require ‘dbcdb/test/all’”

First of all, you should be doing:
ruby dbcdb/test/all.rb
Not your wacky thing with -e and require. Dunno if that will fix it,
but it is standard practice this way.

It does fix it, thanks! I’m trying to remember why I started doing
the require thing - I guess it was the easiest way to get a ruby
command line that worked from Emacs no matter what directory a given
buffer was in.

Still confused as to why the require version doesn’t work, but at
least I can have a happy vacation now!

David C.
[email protected]

6

On Jul 13, 2007, at 22:20 , David C. wrote:

require ‘dbcdb/test/test_book_writer’

  1. GENERALLY: work from the project directory and refer to everything
    from there. Remove ‘dbcdb/’ from those requires.

  2. ruby -w test/all.rb should work fine.

  3. find test -name *.rb – make sure cases are correct and you don’t
    have anything weird like overlapping names. OSX is by default case
    insensitive. Linux is case sensitive. By getting differing numbers of
    tests running it makes me think one of the files is being shadowed.

  4. 1.8.2 on osx is slightly broken, but only for ruby extensions. If
    this is all pure ruby, please ignore.

7

On 7/15/07, David C. [email protected] wrote:

It does fix it, thanks! I’m trying to remember why I started doing
the require thing - I guess it was the easiest way to get a ruby
command line that worked from Emacs no matter what directory a given
buffer was in.

You still shouldn’t do that. Use something like:

ruby -I dbcdb dbcdb/test/all.rb if you must work outside the dir.

8

On Sun, 15 Jul 2007 02:35:07 +0900, 12 34 [email protected]
said:

David C. wrote:

I have a ruby project that I’ve written in a Linux environment. (Ruby
1.8.5, on Ubuntu.) I’d like to work on it on my Mac (Ruby 1.8.2, OSX
10.4) while I’m on vacation, and something weird is happening with my
tests.

I have no idea if this would help, but standard recommendation is to go
to Ruby 1.8.6

Instructions here:
Dan Benjamin

stopping after the gems install.

Thanks for the suggestion and link. I’ve gotten lazy about compiling
stuff from scratch ever since good package management systems showed
up (at least in Linux), but it wouldn’t hurt to get back into the
habit…

David C.
[email protected]

9

On Mon, 16 Jul 2007 00:20:29 +0900, “Gregory B.”
[email protected] said:

On 7/15/07, David C. [email protected] wrote:

On Sat, 14 Jul 2007 23:23:25 +0900, “Chris C.” [email protected] said:

On 7/14/07, David C. [email protected] wrote:

ruby -e “require ‘dbcdb/test/all’”

First of all, you should be doing:
ruby dbcdb/test/all.rb
Not your wacky thing with -e and require. Dunno if that will fix it,
but it is standard practice this way.

It does fix it, thanks! I’m trying to remember why I started doing
the require thing - I guess it was the easiest way to get a ruby
command line that worked from Emacs no matter what directory a given
buffer was in.

You still shouldn’t do that.

I guess I’m curious why using require is good in ruby files but bad
from the command line. Or is it bad in files too? (And, if so,
what’s the replacement?) Is it just an issue of what’s idiomatic (no
problem with that, idioms are important), or am I missing something
deeper?

David C.
[email protected]

10

On Mon, 16 Jul 2007 09:49:33 +0900, “Gregory B.”
[email protected] said:

On 7/15/07, David C. [email protected] wrote:

I guess I’m curious why using require is good in ruby files but bad
from the command line. Or is it bad in files too? (And, if so,
what’s the replacement?) Is it just an issue of what’s idiomatic
(no problem with that, idioms are important), or am I missing
something deeper?

Oh, it’s not really bad in either. The issue is you’re not trying to
require code, you’re trying to run it. Require is used to load just
once, usually to load in libraries.

So what you are doing works fine, but it’s unidiomatic. When you do a
require, you usually won’t expect the code to do anything besides
load class definitions and the like.

Yeah, that’s a good point - makes a lot of sense when you put it it
that way. In fact, maybe the weirdness is that the code does do
anything, given that it’s only class and method definitions! I admit
that it’s convenient that Test::Unit runs tests without being told
when it sees them, but it’s still a strange blurring of boundaries…

Thanks for the insight,
David C.
[email protected]

11

On 7/15/07, David C. [email protected] wrote:

I guess I’m curious why using require is good in ruby files but bad
from the command line. Or is it bad in files too? (And, if so,
what’s the replacement?) Is it just an issue of what’s idiomatic (no
problem with that, idioms are important), or am I missing something
deeper?

Oh, it’s not really bad in either. The issue is you’re not trying to
require code, you’re trying to run it. Require is used to load just
once, usually to load in libraries.

So what you are doing works fine, but it’s unidiomatic. When you do a
require, you usually won’t expect the code to do anything besides
load class definitions and the like.

12

On 7/15/07, David C. [email protected] wrote:

Yeah, that’s a good point - makes a lot of sense when you put it it
that way. In fact, maybe the weirdness is that the code does do
anything, given that it’s only class and method definitions! I admit
that it’s convenient that Test::Unit runs tests without being told
when it sees them, but it’s still a strange blurring of boundaries…

Aha. That makes sense. Test::Unit uses a special collector to do
that, which is why if you want to embed tests in a file, you should
always wrap them with something like:

if FILE == $PROGRAM_NAME
#…
end

to keep them from being run when required as a library. However, in
their test files, you can just work from the main project dir or use
the -I flag to modify the include path.

Hope that helps,
-greg