[Rubygems-developers] Failing to test gem on install
chad at chadfowler.com
Sun Jul 18 19:03:13 EDT 2004
On Sun, 18 Jul 2004, Gavin Sinclair wrote:
# On Sunday, July 18, 2004, 10:24:38 PM, Chad wrote:
# >> With the RubyGems 'test_suite_file', however, it's not so clear.
# >> Would it be worthwhile taking a leaf out of Rake's book here?
# >> spec = Gem::Specification.new do |s|
# >> ...
# >> s.test_files = Dir['test/**/tc_*.rb']
# >> ...
# >> end
# >> A specific reason I'm suggesting this is that a "test suite file"
# >> doesn't seem reusable, in that it doesn't (easily) integrate with
# >> other testing approaches. It seems clumsy to have to create a test
# >> suite file just to appease RubyGems, so why not fold that information
# >> directly into the gemspec?
# > The test_suite_file thing is something that most unit testers do.
# > Nathaniel himself does it. It's idiomatic. In fact, the reason you
# > see "tc_*rb" files is that there are usually also "ts_*rb" files to go
# > with them. :) Nothing RubyGems-specific here.
# 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?
# 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.
#  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. 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.
More information about the Rubygems-developers