[Rubygems-developers] Failing to test gem on install

[Chad Fowler]

On Tue, 20 Jul 2004, Gavin Sinclair wrote:

# 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
# inserted.
#

I'm kind of being extreme here in that, with Ruby's dynamic nature, you
can have the test_file(s) do anything that might result in the definition
of new test cases.  I don't think it's a big deal in terms of this
documentation, though I wouldn't necessarily say that you have to do
requires.

# 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.
#

I don't think it's practical, no.  As above, I was just giving an extreme
case.  I should have said something like "you can create random test cases
depending on what day and time it is" or something obviously ridiculous.
:)


# Any other ideas for the wording of the above text?
#

I think it's good.

# > 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".
#
# Gavin
#
# _______________________________________________
# Rubygems-developers mailing list
# Rubygems-developers at rubyforge.org
# http://rubyforge.org/mailman/listinfo/rubygems-developers
#