C# Unit Testing - Should you unit test something in a derived class that is taken care of in a base class?

public class Foo<T>
{
    public Foo(Bar bar)
    {
        if (bar == null) throw new ArgumentNullException("bar");
    }
}

public class Foo : Foo<Object>
{
    public Foo(Bar bar) : base(bar) { }
}

Basically, I understand that I should unit test the constructor for the Generic Foo. Should I also unit test the constructor for the non-generic version? The reason I ask is because the exception is being thrown at the generic constructor level...

[TestMethod]
[ExpectedExeption(typeof(ArgumentNullException))]
public void GenericFooNullArgumentInConstructor()
{
开发者_Python百科    var foo = new Foo<int>(null);
}

//Is this test necessary?
[TestMethod]
[ExpectedExeption(typeof(ArgumentNullException))]
public void NonGenericFooNullArgumentInConstructor()
{
    var foo = new Foo(null);
}

---

Yes. Without looking at all the implementations, that's the easiest way to verify that your derived classes have maintained the guarantees of your base class. Especially when Bob the intern comes in later and modifies your derived class to do something else.

---

In one word: Yes.
The key here is regression - you'd write the unit tests to verify your current implementation (or even before implementation if you're TDD), but also you write it to protect yourself from breaking changes of the code in the future.
Since both the base and the sub class may be changed in the future - both should be tested.

---

It depends...

why are you writing unit tests?

1) to test the code you are about to write

2) to test the code you have already written

3) to test the code someone might write in the future

If you're writing code to test something you're about to write, write it for the requirements of the code you're going to write.

If you're writing tests to test your code, test the code you write.

If your writing tests to prevent other people from changing your code, that's not your responsibility.

Example

You have a base class A with a particular method, M. You have tested this method backwards, sideways, and upside down. You then create 3 subclasses of A, and call them B, C, and D. You add new functionality inner methods for class B and C.

You should test the new methods of class B and C, because this code is untested, but the method M from class A is already tested.

You override method M in class D, add code, and then call the base method M. The new override method should be tested, and it must be treated as an entirely new method. The unit test has no way to confirm that the base class's M method has been called.

Writing the same test 4 times doesn't do anyone any good. Each developer should be rewriting tests for the code they write. If that code is tested, and the tests meet requirements, and the tests pass, then the code is good.

Taking the same exam three times in a row is pointless.

On the other hand

We don't live in a perfect world, and if you have a problem with other developers not testing their own code, then you may find it useful to do their job for them. But do realize, it's not your job to test the code they write, that's their job.

Super late update...

You should also test methods which will be directly effected by the new code you are writing. For instance, if you do not change method A, but method A relies on method B, and you override method B, you should consider testing method A in your derived class, since the functionality of method A may have been changed due to it's dependence on method B.

---

You should write unit tests for the derived class too! Unit tests ensures you that the tested class works as you expect it. That gives you the chance to refactor it some day. If then you'll make a mistake while refactoring the constructor of the derived class - no unit test will find that error. (If you haven't wrote unit tests for the derived class).