Asp Forum - Test::Unit - same test, different "args"

Luke St.Clair

3/23/2009 8:50:00 PM

I need to run the same unit test case more than 10 times (around 150
tests in the test case), with 2-3 parameters changed each time.

For instance, if I had unit tests to examine a "Person", with a
required parameter "name" - let's say I want to run the same
Test::Unit::TestCase on 10 different people, with different names but
everything else the same. All test cases run the same code, just with
the one (or two) parameters tweaked.

Let's say I have 150 tests for a Person - I'd rather not end up with
1500 tests, each of the 150 tests exactly duplicated for a different
"name".

I'll have a hierarchy of tests cases, in suites, which may help

Is there some way to:
1) set a global variable in the "parent" test suite that the children
see? Seems like the answer to this is no
2) Pass an arg to the test case as a whole? Don't see anyway to do
this in the docs
3) Do something else that will keep this test code compliant with DRY?

What's the right approach here?

13 Answers

Phlip

3/23/2009 9:38:00 PM

Luke St.Clair wrote:
> I need to run the same unit test case more than 10 times (around 150
> tests in the test case), with 2-3 parameters changed each time.
>
> For instance, if I had unit tests to examine a "Person", with a
> required parameter "name" - let's say I want to run the same
> Test::Unit::TestCase on 10 different people, with different names but
> everything else the same. All test cases run the same code, just with
> the one (or two) parameters tweaked.

Put all the test_ methods into a module, and include it into 10 different suites:

class ATest < Test::Unit::TestCase; include Suite; setup; @me = 'a'; end; end
class BTest < Test::Unit::TestCase; include Suite; setup; @me = 'b'; end; end
class CTest < Test::Unit::TestCase; include Suite; setup; @me = 'c'; end; end
class DTest < Test::Unit::TestCase; include Suite; setup; @me = 'd'; end; end

there might be a less effusive way, but the Abstract Test Pattern is very
important to learn, so this is a good start...

> What's the right approach here?

Abstract Test is best to match an important class hierarchy in your code.
Otherwise, the question arises are you missing an abstraction? Could you
simplify something else, and test fewer permutations?

Brian Candler

3/23/2009 10:02:00 PM

Luke St.Clair wrote:
> Is there some way to:
> 1) set a global variable in the "parent" test suite that the children
> see? Seems like the answer to this is no

Shoulda sits on top of Test::Unit and may be helpful. Something like
this:

class MyTest < Test::Unit::TestCase
context "top level" do
setup do
@stuff = ...
end

should "test something at top level" do
assert_equal 123, @stuff.size
end

context "inner level" do
setup do
@more_stuff = ...
end

should "test more" do
assert_equal @stuff.size, @more_stuff.size
end
end
end
end

See:
http://www.thoughtbot.com/projec...
http://mtnwestrubyconf2008.confreaks.com/12...
http://tammersaleh.com/system/assets/bdd_with_s...
--
Posted via http://www.ruby-....

Luke St.Clair

3/24/2009 7:39:00 PM

On Mar 23, 2:38 pm, Phlip <phlip2...@gmail.com> wrote:
> Luke St.Clair wrote:
> > I need to run the same unit test case more than 10 times (around 150
> > tests in the test case), with 2-3 parameters changed each time.
>
> > For instance, if I had unit tests to examine a "Person", with a
> > required parameter "name" - let's say I want to run the same
> > Test::Unit::TestCase on 10 different people, with different names but
> > everything else the same. All test cases run the same code, just with
> > the one (or two) parameters tweaked.
>
> Put all the test_ methods into a module, and include it into 10 different suites:
>
> class ATest < Test::Unit::TestCase; include Suite; setup; @me = 'a'; end; end
> class BTest < Test::Unit::TestCase; include Suite; setup; @me = 'b'; end; end
> class CTest < Test::Unit::TestCase; include Suite; setup; @me = 'c'; end; end
> class DTest < Test::Unit::TestCase; include Suite; setup; @me = 'd'; end; end
>
> there might be a less effusive way, but the Abstract Test Pattern is very
> important to learn, so this is a good start...
>
> > What's the right approach here?
>
> Abstract Test is best to match an important class hierarchy in your code.
> Otherwise, the question arises are you missing an abstraction? Could you
> simplify something else, and test fewer permutations?

I think this is what I'm going to go with - I'll have a test case for
each possible param value (there are about 10), and each one will set
a few additional global variables. Then, each test case will include
the same module, which will call functions with params set by the
global variables.

Seems to be very DRY, as long as the set of param values is small (it
is in this case, and should stay small in the future).

Thanks -

Luke St.Clair

3/24/2009 7:53:00 PM

On Mar 23, 3:02 pm, Brian Candler <b.cand...@pobox.com> wrote:
> Luke St.Clair wrote:
> > Is there some way to:
> > 1) set a global variable in the "parent" test suite that the children
> > see? Seems like the answer to this is no
>
> Shoulda sits on top of Test::Unit and may be helpful. Something like
> this:
>
> class MyTest < Test::Unit::TestCase
> context "top level" do
> setup do
> @stuff = ...
> end
>
> should "test something at top level" do
> assert_equal 123, @stuff.size
> end
>
> context "inner level" do
> setup do
> @more_stuff = ...
> end
>
> should "test more" do
> assert_equal @stuff.size, @more_stuff.size
> end
> end
> end
> end

This seems incredibly useful - unfortunately, I can't use shoulda.

Brian Candler

3/24/2009 11:20:00 PM

Luke St.Clair wrote:
> This seems incredibly useful - unfortunately, I can't use shoulda.

Out of interest, why not? Policy constraint?
--
Posted via http://www.ruby-....

Luke St.Clair

3/25/2009 11:29:00 PM

On Mar 24, 12:39 pm, "Luke St.Clair" <secureb...@gmail.com> wrote:

> I think this is what I'm going to go with - I'll have a test case for
> each possible param value (there are about 10), and each one will set
> a few additional global variables. Then, each test case will include
> the same module, which will call functions with params set by the
> global variables.

The biggest issue I'm running into right now is not having startup(),
or code that runs once per test suite, not once per test case.

Is this in test::unit yet?

Luke St.Clair

3/25/2009 11:29:00 PM

On Mar 24, 4:20 pm, Brian Candler <b.cand...@pobox.com> wrote:
> Luke St.Clair wrote:
> > This seems incredibly useful - unfortunately, I can't use shoulda.
>
> Out of interest, why not? Policy constraint?
> --
> Posted viahttp://www.ruby-....

Basically, yes.

Luke St.Clair

3/25/2009 11:39:00 PM

On Mar 25, 4:29 pm, "Luke St.Clair" <secureb...@gmail.com> wrote:
> On Mar 24, 12:39 pm, "Luke St.Clair" <secureb...@gmail.com> wrote:
>
> > I think this is what I'm going to go with - I'll have a test case for
> > each possible param value (there are about 10), and each one will set
> > a few additional global variables. Then, each test case will include
> > the same module, which will call functions with params set by the
> > global variables.
>
> The biggest issue I'm running into right now is not having startup(),
> or code that runs once per test suite, not once per test case.
>
> Is this in test::unit yet?

Better yet, is there some way to get around this?

Right now, I have like 8 test suite files, which do something like:

initialize_things(foo)

class MyTester < Test::Unit::TestCase
include cases1
include cases2
end

This works fine if I run the file directly, but I want a "master" test
runner that would require MyTester, MyOtherTester, MyFinalTester,
etc. In this case, initialize_things doesn't get called.

How can I replicate this startup() functionality that I need? I do
NOT want to use setup(), as it slows things down considerably.

Phlip

3/25/2009 11:40:00 PM

Luke St.Clair wrote:

> The biggest issue I'm running into right now is not having startup(),
> or code that runs once per test suite, not once per test case.
>
> Is this in test::unit yet?

There are code samples and I think plugins which add that.

How about in the base module...

def setup
@@done ||= suite_setup()
end

Then put what you want in the suite_setup ?

Luke St.Clair

3/26/2009 12:01:00 AM

On Mar 25, 4:39 pm, Phlip <phlip2...@gmail.com> wrote:
> Luke St.Clair wrote:
> > The biggest issue I'm running into right now is not having startup(),
> > or code that runs once per test suite, not once per test case.
>
> > Is this in test::unit yet?
>
> There are code samples and I think plugins which add that.
>
> How about in the base module...
>
> def setup
> @@done ||= suite_setup()
> end
>
> Then put what you want in the suite_setup ?

Yes, that's clearly the best way for me to do this outside of startup
() - don't know what I was thinking there.

comp.lang.ruby

Test::Unit - same test, different "args"

Luke St.Clair

Phlip

Brian Candler

Luke St.Clair

Luke St.Clair

Brian Candler

Luke St.Clair

Luke St.Clair

Luke St.Clair

Phlip

Luke St.Clair

x Login to ForumsZone