[ruby-talk:4660] Re: RubyUnit testcase run for different init params?

Based on the previous discussion and the solution I ended up using I'd
suggest the following change to RubyUnit:

* When printing out info about a failure RUNIT::CUI:TestRunner should
print not only the file name and line number but the name of the class. 

If the same test class is used for testing different parameter
combinations you may not know which combination was used (if you don't add
them to each and every assert error msg).

Example from current RubyUnit with test code below:

tests/Test_Rng.rb:126:in `test_07_rand_bignum': cnt = 0 The condition is
<false: FalseClass> (RUNIT::AssertionFailedError)
        from tests/Test_Rng.rb:196

which I think should be

tests/Test_Rng.rb:126:in `Test_Rng_mt19937::test_07_rand_bignum': cnt = 0
The condition is <false: FalseClass> (RUNIT::AssertionFailedError)
        from tests/Test_Rng.rb:196

Comments? Do you think this is so specific I should override RubyUnit
myself? Other ways to do it, Masaki?

Regards,

Robert

Code I use (Random::RngAlgorithms is Array with parameters I want to
test. All tests use @r.):

def derived_test_rng_class(alg)
  "class Test_Rng_%s < Test_Rng\n" % alg +
  "  def setup\n" +
  "    @r = Rng.new('%s')\n" % alg +
  "    @alg = '%s'\n" % alg +
  "  end\n" +
  "end\n"
end

class Test_Rng < RUNIT::TestCase

  # Create subclasses for all the algorithms we want to test
  def Test_Rng.full_suite
    suite = RUNIT::TestSuite.new
    Random::RngAlgorithms.each{ |alg|
      code_for_new_class = derived_test_rng_class(alg)
      eval( code_for_new_class )
      suite.add_test( eval( "Test_Rng_%s.suite" % alg ) )
    }
    suite
  end

  # Lots of tests here...
end

On Mon, 28 Aug 2000, Dave Thomas wrote:

> Robert Feldt <[e-mail]> writes:
> 
> > You have a point there but I'm still surprised why you don't suggest
> > code generation. To be specific in the ruby extension for Random number
> > generation we're working on we don't know (at the time of writing the
> > tests) what parameters to RandomNumberGenerator are valid (currently you
> > have a choice of 33 different RNG algorithms stored in
> > Random::RngAlgorithms but that changes as we add/subtract new/bad algs).
> > So it's pretty simple to generate the code for the test classes you
> > suggested previously.
> 
> True - in this particular case, where (presumably) the constructors all 
> look alike, then you could have a single test driver that used  this
> array of names (or whatever) to build and run yours tests. If there
> was a regular pattern like this, I probably would use some form of
> automatically generated list. For just three cases, I probably
> wouldn't unless it was a real pain setting the tests up.
> 
> 
> > However, in a general case the parameters to a class might be arbitrarily
> > complex (involving large parse trees or what-have-you) so people would
> > probably need a way to dynamically parameterize TestCase-derived classes.
> > Could you do it with Binding's (ie. saving the state at the time of
> > creating the class with a certain parameter)?
> 
> An easier way might be to use a factory method that hid this
> intelligence within the class itself (or a helper). However, again,
> I'd do this in a subclass of the class being tested, so that users of
> the real class didn't have to have all this test-specific code lying
> around.
> 
> 
> Regards
> 
> 
> Dave
> 
> 

---------------------------------------------------------------
Robert Feldt	tel: [phone] fax: [phone]
[e-mail] or [e-mail]
MSc, Ph.D. student
Chalmers Univ. of Technology, Dept. of Computer Engineering
Hsalsv臠en 11, SE-412 96 Gothenburg, Sweden