Nunit 2.5.0.9122: setup not called when test method is inherited from a base method

[Ngu Soon Hui]

I found that the Setup method wont' be called if my test method is
inherited from a base method.

Here's the code, the below test will fail:

public class SetupCallBase
{
protected int setupCount = 0;
public virtual void Init()
{
setupCount++;
}

public virtual void AssertCount()
{

}
}

[TestFixture]
public class SetupCallDerived: SetupCallBase
{
[SetUp]
public override void Init()
{
setupCount++;
base.Init();
}


[Test]
public override void AssertCount()
{

Assert.AreEqual(2, setupCount);
}

}

As far as I know NUnit 2.4 will have the above test pass.

On the other hand, the test will also pass if I don't make the
AssertCount as virtual/override.

[Charlie Poole]

Hi,

> I found that the Setup method wont' be called if my test
> method is inherited from a base method.
>
> Here's the code, the below test will fail:
>
> public class SetupCallBase
> {
> protected int setupCount = 0;
> public virtual void Init()
> {
> setupCount++;
> }
>
> public virtual void AssertCount()
> {
>
> }
> }
>
> [TestFixture]
> public class SetupCallDerived: SetupCallBase
> {
> [SetUp]
> public override void Init()
> {
> setupCount++;
> base.Init();
> }
>
>
> [Test]
> public override void AssertCount()
> {
>
> Assert.AreEqual(2, setupCount);
> }
>
> }

So what is setupCount equal to?

> As far as I know NUnit 2.4 will have the above test pass.
>
> On the other hand, the test will also pass if I don't make
> the AssertCount as virtual/override.

This could be a bug, but if so its priority would depend
on the usefulness of the technique you are using. Can you
explain why you want to do this?

Charlie

>
> >
>

[Charlie Poole]

Hi...

I'm putting us back on the list.

> The setupCount should be equaled to 2.

What *is* it equal to.

> The reason why I am doing this is because I need to access
> the Setup method in my tests. In Nunint 2.5, under the
> scenario I give, the setup method is completely bypassed.
> Since I have written a large amount of tests in this fashion,
> now all of the tests fail because the setup method is not called.

My question was what is the use case for overriding the a test
method in a base class. What are you trying to accomplish? Why
not simply have a different named method in the derived class?

Charlie

> Note that this problem only occurs when you have a debugger
> attached ( i.e, whether running in Testdriven.net or NUnit
> gui), if you don't have a debugger, then there is no such problem.

[Ngu Soon Hui]

> What *is* it equal to.

It is equal to 0, but it should be equaled to 2.

> My question was what is the use case for overriding the a test
> method in a base class. What are you trying to accomplish? Why
> not simply have a different named method in the derived class?
>

I could have done that, if I were to start all over again. But since
they were written long time ago ( and at the time of writing they
worked!), and so I wish not to change it now, even though I upgrade
the NUnit framework.

[Charlie Poole]

Hi,

> > What *is* it equal to.
> It is equal to 0, but it should be equaled to 2.

OK

> > My question was what is the use case for overriding the a
> test method
> > in a base class. What are you trying to accomplish? Why not simply
> > have a different named method in the derived class?
> >
>
> I could have done that, if I were to start all over again.
> But since they were written long time ago ( and at the time
> of writing they worked!), and so I wish not to change it now,
> even though I upgrade the NUnit framework.

OK, we'll try to replicate the bug and see if we agree it's
a problem. But sometimes bugs don't get a very high priority
if we can't understand why a person would want to do a certain
thing. More explanation would help both us and you.

Charlie

[Soon Hui Ngu]

OK, we'll try to replicate the bug and see if we agree it's

a problem. But sometimes bugs don't get a very high priority

if we can't understand why a person would want to do a certain

thing. More explanation would help both us and you.

All I can say is that since this is a behavior change, and that a lot of tests are written in this way, and that this is the intuitive way the program should work, therefore you should consider fixing this.

In addition to that, if I run the tests without a debugger ( the above problem only occurs if you are running your tests with a debugger)

Thanks for your prompt attention, not many open source developers pay great notice to support :)

[Charlie Poole]

All I can say is that since this is a behavior change, and that a lot of tests are written in this way, and that this is the intuitive way the program should work, therefore you should consider fixing this.

 So we remember this, can you file a bug report please?

 

Charlie 

[MinnowNoir]

I'm having the same problem with 2.5.2.9222.

The reason I am overriding test methods (and, hopefully, the "setup"
method) is that I have several classes-under-test that implement the
same interface. Rather than copy and paste all of my test cases from
one file to the next, I extracted a abstract superclass, overrided the
test and setup methods in the derived classes, then moved the [SetUp]
and [Test] attributes from the base class to the derived classes.
Scanning the web and Roy Osherove's book, it looks like this was/is a
common practice. I do test some MTA code in this test project, so
reverting to an earlier version of NUnit is not an option for me.

Charlie: Since you seem surprised that someone would do what Soon Hui
Ngu and I are doing, can you tell me what you think we ought to be
doing? I'm okay with alternatives, as long as they don't involve
copying and pasting code around and then having to fix it in multiple
places.

Thanks

[MinnowNoir]

BTW, it looks like using composition (taking a reference to the base
class and then calling its methods through the reference) works just
fine, so maybe that's the preferable route. Is that what everyone
else does in this situation?

[Charlie Poole]

Hi,

> On Oct 2, 3:57 am, "Charlie Poole" <char...@nunit.com> wrote:
> > All I can say is that since this is a behavior change, and
> that a lot
> > of tests are written in this way, and that this is the
> intuitive way
> > the program should work, therefore you should consider fixing this.
> >
> >  So we remember this, can you file a bug report please?
> >
> > Charlie
>
> I'm having the same problem with 2.5.2.9222.
>
> The reason I am overriding test methods (and, hopefully, the "setup"
> method) is that I have several classes-under-test that
> implement the same interface. Rather than copy and paste all
> of my test cases from one file to the next, I extracted a
> abstract superclass, overrided the test and setup methods in
> the derived classes, then moved the [SetUp] and [Test]
> attributes from the base class to the derived classes.
> Scanning the web and Roy Osherove's book, it looks like this
> was/is a common practice. I do test some MTA code in this
> test project, so reverting to an earlier version of NUnit is
> not an option for me.

That's exactly how it's designed to work.

> Charlie: Since you seem surprised that someone would do what
> Soon Hui Ngu and I are doing, can you tell me what you think
> we ought to be doing? I'm okay with alternatives, as long as
> they don't involve copying and pasting code around and then
> having to fix it in multiple places.

My surprise was that Soon Hui Ngu wanted a non-abstract base
class to be called automatically. Since he never explained why
he needed to do this, I didn't provide an alternate solution.

If you override a virtual method in a derived class, you're
telling the compiler you want the derived method to be used
in place of the base method. There should be no expectation
that *both* methods will be called automatically.

In summary...

To set up a series of tests that *must* be defined in a
derived class...

* Use abstract methods, placing the attribute on the override

To set up common test methods using a template pattern

* Use non-virtual methods in the base, relying on abstract
helpers that must be implemented in the derived class

To have some tests in the base and some in the derived class

* Just put the methods in the preferred class

To have common setup in the base and additional setup in the
derived class

* Put methods (with different names) in both classes and
use the SetUp attribute on both of them.

Does this clarify things?

Charlie
in the base class
> Thanks
>
> >
>

[Charlie Poole]

Hi,

> BTW, it looks like using composition (taking a reference to
> the base class and then calling its methods through the
> reference) works just fine, so maybe that's the preferable
> route. Is that what everyone else does in this situation?

This is the way to achieve reuse below the level of a whole
test or setup method. It's also what you previously had to
do for setup and teardown before we introduced multiple levels
of setup/teardown in a hierarchy.

Charlie