[Rubygems-developers] Failing to test gem on install
gsinclair at soyabean.com.au
Sun Jul 18 22:31:56 EDT 2004
> # I've never seen a "ts_*.rb" file, and am digging through various
> # projects' code now to try and get an idea for unit testing practice.
> # Do you know of any good examples?
> I'd look to Nathaniel for good examples. You're on Dave's pickaxe2
> review list, right? Have you looked at his unit testing chapter?
Good idea; I will tonight.
> # The fact remains that it's quite reasonable to manage unit tests
> # _without_ such suite files. I prefer to do so. So why should
> # RubyGems target just one idiom?
> It's not really targeting just one idiom. It currently requires that
> you identify one file that, when loaded, will cause all of your test
> cases to load. You can do that however you want. We could probably
> even support some kind of Rakefile. You could get them out of a
> database, generate them randomly, require them from tc_*rb files,
> whatever. I don't think it can get much more flexible. We _could_ add
> a #test_files attribute to the gem specification, but we're probably
> already going to have to add something like #test_require_path, and I
> don't think it's worth cluttering the gem spec up even further for this.
But I reckon a 'test_files' attribute would be enough in isolation. (Or
perhaps a 'test_files_pattern', like 'test/test*.rb', would be better.)
Why is a 'test_require_path' needed? If you have an array of test files,
relative to the root of the gem, you can *load* them (not 'require') one
by one, and then do the ObjectSpace thing. You just have to make sure
that the correct libraries (the ones being tested) are at the front of the
The unit tests are responsible for loading any supporting files (i.e. they
need to know where they are using __FILE__). The unit tests should not be
responsible for manipulating LOAD_PATH, though. That's better handled by
an outside agent, be it RubyGems, Rake, or test/TEST.rb.
I'm definitely interested in minimising gemspec clutter, which is why I
think 'test_files_pattern' is the best solution. It's easy to specify,
and has no dependencies on anything else, within or without the gemspec.
> #  I go for a test/TEST.rb file that can be run from anywhere, and
> # allows you to restrict the test suite on the command line.
> mv test/TEST.rb test/ts_test.rb and you essentially have the equivalent
> of what most ts_*rb files do.
As it happens, it probably does. But it also does LOAD_PATH twiddling,
which (as I said above) is something RubyGems should be doing itself.
> Personally, I'm against the addition of command options to support
> command-line-driven restrictions on test running for gems, but you're
> not suggesting that.
No, I wouldn't suggest that. CL-driven restrictions are useful during
development, nothing else.
More information about the Rubygems-developers