[Rubygems-developers] Failing to test gem on install

Jim Weirich jim at weirichhouse.org
Mon Jul 19 12:32:01 EDT 2004


Chad Fowler said:
>
>
> On Tue, 20 Jul 2004, Gavin Sinclair wrote:
>
> # On Monday, July 19, 2004, 11:22:28 PM, Chad wrote:
> #
> # > # 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.
> # > #
> #
> # > After giving this some thought, I think the best way to do this is to
> # > remain consistent with some of the other attributes that allow either
> one
> # > or many values that point to files (like "extensions",
> "require_paths",
> # > etc.).  We could rename the current #test_suite_file to #test_file and
> # > then have a plural version #test_files.  Ultimately, they could all be
> # > typical ts_* style test suite files, or any other custom thing that
> loads
> # > TestCases.
> #
> # > 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.  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.

Looks good.  Regarding singular/plural:  We should either support
singular/plural whereever it makes sense, or support it nowhere.

Other things that should be specified, but probably don't need options for:

* When the test cases are run, the current directory should be the base of
the gem directory.  This allows test code to reliably find test data and
whatnot without specifying an absolute path or doing fancy calculates.  I
see no need for an option to change this.

* The current directory (".") should be in the load path.  I think this is
the default in all the ruby installs I've seen, but perhaps we need to
insure this.

* Any require_paths specified in the Gem spec are in the load path.

I think the above conditions are reasonable starting conditins for any
test suites.  They need to be clearly stated so that developers know they
can depend on the conditions.  If someone needs something that doesn't fit
into the above, then they can provide a suite file that modifies the
environment as they see fit, and put that suite_file in test_file.

-- 
-- Jim Weirich     jim at weirichhouse.org    http://onestepback.org
-----------------------------------------------------------------
"Beware of bugs in the above code; I have only proved it correct,
not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)



More information about the Rubygems-developers mailing list