[Rubygems-developers] Failing to test gem on install
gsinclair at soyabean.com.au
Sun Jul 18 02:29:09 EDT 2004
On Sunday, July 18, 2004, 2:14:59 AM, Chad wrote:
> # Then a Test::Unit::TestSuite is built up from all TestCase classes in
> # the object space.
> # So what would such a test_suite_file look like? A bunch of require
> # statements by the sound of it. Is this a committed design decision?
> Any file that causes TestCases to be defined will work. This means it can
> be a list of requires or a single-file set of tests. Whatever you like.
> For small projects, it might make sense to include all of the tests in the
> test_suite_file, while for larger ones you could just require all of your
> "tc_*.rb" files from the central file.
Running tests is always a tricky area, as you need to be sure you're
testing against the "fresh" library code as opposed to the installed
I like Rake's approach:
Rake::TestTask.new do |t|
t.libs = ['lib'] # This is default; just highlighting it.
t.pattern = 'test/**/tc_*.rb'
t.verbose = true
As a developer, it's pretty clear what's going on here with respect to
load path, etc. Despite that, the RubyGems Rakefile defines its own
unit testing target. In my own projects, I do too, so that I can
specify on the command-line a subset of tests to run if I wish.
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']
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?
Of course, my window into the world of testing doesn't allow me to see
the full picture, so I merely express my views here, rather than assert
It seems that I'll reluctantly release an 'extensions' gem without a
unit testing specification, since it wouldn't work anyway (i.e. the
current RubyGems code is broken), and there's scope for change in the
More information about the Rubygems-developers