[Rubygems-developers] Failing to test gem on install
gsinclair at soyabean.com.au
Mon Jul 19 11:49:12 EDT 2004
On Tuesday, July 20, 2004, 12:57:13 AM, Chad wrote:
> >> Any other test-oriented people have an opinion?
> # That sounds nice and logical. So the documentation (in the mould of
> # GemspecReference) would read something like this?
> # == test_files ==
> # Type: Array; Optional; Default = 
> # === Description ===
> # A collection of unit testing files, each of which will be loaded if
> # the user asks to unit test the gem. The expected result of loading
> # each file is the definition of one or more Test::Unit::TestCase
> # classes.
> # === Usage ===
> # # Load a suite which will include all unit tests.
> # spec.test_files << "test/all_tests.rb"
> # # Specify all unit test files explicitly.
> # spec.test_files = Dir["test/**/tc_*.rb"]
> # === Notes ===
> # The above example shows two different approaches to specifying the
> # test files. In the first case, a single "test suite" file will
> # <tt>require</tt> all of the project's unit tests. In the second
> # case, all unit tests are specified explicitly in the gemspec.
> # When the unit tests are run, the RubyGems front-end will ensure that
> # the gem's libraries are being tested (see L(require_paths)).
> # I'm sure some of that could be better worded, but ss that what you had
> # in mind?
> # Is there are need for a singular version ('test_file')?
> Right. Though, you wouldn't necessarily have to require all of the
> project's unit tests in that single file. You could calculate and define
> them in any way you like.
Apart from defining all the test cases in the one file, what other
approach is there, apart from requiring all the tests? You can
require other suites. The requires can be static or dynamic. But the
way I see it, a "test file" needs to either define some test cases, or
load them from elsewhere. The documentation posited above would
perhaps be improved with a "(directly or indirectly)" strategically
Hmmm... you mentioned loading tests from a database. Interesting
idea, but probably not practical in a gem situation, wouldn't you say?
A gem has to be a static code snapshot.
Any other ideas for the wording of the above text?
> They could all even be in the one file if it were a small project. I
> like the singlular version as a shortcut. I'm guessing that there
> will be a lot of people who will use either way.
There's precedent for that. As the reference shows:
spec.require_path = '.'
# If you have 'lib' and 'ext' directories...
spec.require_paths << 'ext'
In that case, the documented "attribute" is called "require_paths",
with "require_path" noted as a shortcut. I'd gladly support the same
arrangement with "test_file/s".
More information about the Rubygems-developers