overriding setup in Test::Unit

Discussion in 'Ruby' started by Ian Macdonald, Feb 4, 2004.

  1. Hello,

    I have some unit tests that I'm having a little trouble with.

    This is basically the set-up:

    class TC_Foo < Test::Unit::TestCase
    def setup
    ...
    end

    def test_method1
    ...
    end

    def test_method2
    ...
    end
    end

    class TC_Bar < TC_Foo
    def setup
    ...
    end

    def test_method1
    ...
    end

    # TC_foo#method2 will get called for

    end


    All the tests for TC_Foo work as expected. The problem comes with
    TC_Bar. I want TC_Bar#setup to be called prior to each of the unit tests
    in that class, but I can't seem to make that happen. Instead,
    TC_Foo#setup is called, which is not what I want at all.

    I've tried explicitly undefining the setup method in TC_Bar with
    'undef_method :setup', but even that doesn't work.

    There must be a way to do this, right?

    Ian
    --
    Ian Macdonald | The clothes have no emperor. -- C.A.R.
    System Administrator | Hoare, commenting on ADA.
    |
    http://www.caliban.org |
    |
    Ian Macdonald, Feb 4, 2004
    #1
    1. Advertising

  2. On Wed 04 Feb 2004 at 17:11:26 +0900, Ian Macdonald wrote:

    > Hello,
    >
    > I have some unit tests that I'm having a little trouble with.
    >
    > This is basically the set-up:
    >
    > class TC_Foo < Test::Unit::TestCase
    > def setup
    > ...
    > end
    >
    > def test_method1
    > ...
    > end
    >
    > def test_method2
    > ...
    > end
    > end
    >
    > class TC_Bar < TC_Foo
    > def setup
    > ...
    > end
    >
    > def test_method1
    > ...
    > end
    >
    > # TC_foo#method2 will get called for
    >
    > end
    >
    > All the tests for TC_Foo work as expected. The problem comes with
    > TC_Bar. I want TC_Bar#setup to be called prior to each of the unit tests
    > in that class, but I can't seem to make that happen. Instead,
    > TC_Foo#setup is called, which is not what I want at all.
    >
    > I've tried explicitly undefining the setup method in TC_Bar with
    > 'undef_method :setup', but even that doesn't work.
    >
    > There must be a way to do this, right?


    In the example above, I have renamed the classes from their true names.
    Interestingly, I now note that I get the correct overriding behaviour if
    the subclass of TC_Foo has a name that alphabetically sorts earlier.

    In other words, the code as shown above actually works, because TC_Bar
    (the subclass) sorts higher than TC_Foo (the superclass). If I change
    the name of the TC_Bar class to TC_Goo, however, TC_Foo#setup is no
    longer overridden by the method of the same name in the subclass.

    This seems like an odd and arbitrary way to go about things. Is this the
    intention or some obscure side-effect of my trying to do something
    irrational?

    Ian
    --
    Ian Macdonald | War spares not the brave, but the cowardly.
    System Administrator | -- Anacreon
    |
    http://www.caliban.org |
    |
    Ian Macdonald, Feb 4, 2004
    #2
    1. Advertising

  3. Ian Macdonald

    Guest

    Hi,

    At Wed, 4 Feb 2004 17:26:54 +0900,
    Ian Macdonald wrote in [ruby-talk:91524]:
    > In the example above, I have renamed the classes from their true names.
    > Interestingly, I now note that I get the correct overriding behaviour if
    > the subclass of TC_Foo has a name that alphabetically sorts earlier.
    >
    > In other words, the code as shown above actually works, because TC_Bar
    > (the subclass) sorts higher than TC_Foo (the superclass). If I change
    > the name of the TC_Bar class to TC_Goo, however, TC_Foo#setup is no
    > longer overridden by the method of the same name in the subclass.
    >
    > This seems like an odd and arbitrary way to go about things. Is this the
    > intention or some obscure side-effect of my trying to do something
    > irrational?


    Seems fine.

    $ cat test.rb
    class TC_Foo < Test::Unit::TestCase
    def setup
    puts "Foo#setup"
    end

    def test_method1
    assert_nothing_raised {puts "Foo#test_method1"}
    end

    def test_method2
    assert_nothing_raised {puts "Foo#test_method2"}
    end
    end

    class TC_Goo < TC_Foo
    def setup
    puts "Goo#setup"
    end

    def test_method1
    assert_nothing_raised {puts "Goo#test_method1"}
    end

    # TC_foo#method2 will get called for

    end
    $ testrb -vs test.rb
    Foo#setup
    Foo#test_method1
    Foo#setup
    Foo#test_method2
    Goo#setup
    Goo#test_method1
    Goo#setup
    Foo#test_method2

    --
    Nobu Nakada
    , Feb 4, 2004
    #3
  4. On Wed 04 Feb 2004 at 18:21:33 +0900, wrote:

    > Seems fine.
    >
    > $ cat test.rb
    > class TC_Foo < Test::Unit::TestCase
    > def setup
    > puts "Foo#setup"
    > end
    >
    > def test_method1
    > assert_nothing_raised {puts "Foo#test_method1"}
    > end
    >
    > def test_method2
    > assert_nothing_raised {puts "Foo#test_method2"}
    > end
    > end
    >
    > class TC_Goo < TC_Foo
    > def setup
    > puts "Goo#setup"
    > end
    >
    > def test_method1
    > assert_nothing_raised {puts "Goo#test_method1"}
    > end
    >
    > # TC_foo#method2 will get called for
    >
    > end
    > $ testrb -vs test.rb
    > Foo#setup
    > Foo#test_method1
    > Foo#setup
    > Foo#test_method2
    > Goo#setup
    > Goo#test_method1
    > Goo#setup
    > Foo#test_method2


    The real code is more complex, of course. A lot of files are being
    'require'd and there are modules being mixed in, too, so I think I'm
    experiencing some weird interaction there.

    Thanks for your help.

    Ian
    --
    Ian Macdonald | The only cultural advantage LA has over NY
    System Administrator | is that you can make a right turn on a red
    | light. -- Woody Allen
    http://www.caliban.org |
    |
    Ian Macdonald, Feb 4, 2004
    #4
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. VvanN
    Replies:
    5
    Views:
    476
    Phlip
    Apr 28, 2006
  2. Bill David
    Replies:
    2
    Views:
    261
    Arne Vajhøj
    Jun 18, 2008
  3. Replies:
    2
    Views:
    164
    Bret Pettichord
    Oct 7, 2005
  4. Bill Mosteller
    Replies:
    0
    Views:
    209
    Bill Mosteller
    Oct 22, 2009
  5. timr
    Replies:
    2
    Views:
    152
Loading...

Share This Page