Bugs item #27507, was opened at 2009-12-01 17:36 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27507&group_id=126
Category: `gem install` command Group: None Status: Open Resolution: Accepted Priority: 3 Submitted By: Ryan Davis (zenspider) Assigned to: Ryan Davis (zenspider) Summary: Remove -t from gem install Initial Comment: this is a message body. ---------------------------------------------------------------------- >Comment By: Daniel Berger (djberg96) Date: 2010-11-13 08:06 Message: I would argue that requiring the user to check out the source and run the tests is generally going to be a burden most people won't waste their time on. They'll just assume that it works. I'm tainted by my Perl background here, but with CPAN all tests are run automatically (by default) when installing via the CPAN shell. The module will not install if any tests fail, except by force. In addition, test failures can be automatically reported to the CI farm that they've setup. Perl has multiple testing frameworks, yet somehow they manage to work. I think we're going down the wrong path here. I'd rather establish that all gems follow some sort of convention (perhaps in the spec) with regards to testing, and how tests should be run, that the "-t" option could then hook into. Regards, Dan ---------------------------------------------------------------------- Comment By: Luis Lavena (luislavena) Date: 2010-11-13 07:27 Message: Yes please. Lot of projects do testing differently. Even if you declare all the development dependencies it also depend on certain tools or certain services been installed in the user machine. These are not self contained. If the user wants to run tests, then look for the source, clone/checkout and follow the developer instructions. That is more easy than maintain a command that cannot solve all the aspects of "testing" a gem. ---------------------------------------------------------------------- Comment By: John Barnette (jbarnette) Date: 2010-11-13 07:00 Message: I think -t should die. Other folks? ---------------------------------------------------------------------- Comment By: Chad Woolley (thewoolleyman) Date: 2009-12-03 09:29 Message: I meant a property in the gem spec which would point to an executable test suite script - e.g. spec.test_script = test/test_suite.rb. If this property existed, it would be used and the return code from the script would indicate test success/failure. May be overkill and not worth modifying the spec; it was just an idea to allow people to use any testing framework they want. ---------------------------------------------------------------------- Comment By: Daniel Berger (djberg96) Date: 2009-12-03 01:15 Message: Chad, what do you mean by a "test suite script"? I was thinking a -r option to run the 'test' Rake task, if it exists. I also realized that the approach suggested won't work for rspec, for example, because simply requiring an rspec test script doesn't generate any output. It looks like it assumes you're always running 'spec' from the command line directly. Regards, Dan ---------------------------------------------------------------------- Comment By: Chad Woolley (thewoolleyman) Date: 2009-12-01 19:49 Message: 'Is there a reason we can't just make -t run "ruby -I spec.lib spec.test_files"' - good idea. And/or add an additional spec parameter for a test suite script... ---------------------------------------------------------------------- Comment By: Daniel Berger (djberg96) Date: 2009-12-01 19:45 Message: Is there a reason we can't just make -t run "ruby -I spec.lib spec.test_files" ? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27507&group_id=126 _______________________________________________ Rubygems-developers mailing list http://rubyforge.org/projects/rubygems Rubygems-developers@rubyforge.org http://rubyforge.org/mailman/listinfo/rubygems-developers
