C# 单元测试 - 您是否应该对派生类中由基类处理的某些内容进行单元测试？
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) { }
}
基本上，我知道我应该对 Generic Foo 的构造函数进行单元测试。我还应该对非通用版本的构造函数进行单元测试吗？我问的原因是因为异常是在通用构造函数级别引发的......
[TestMethod]
[ExpectedExeption(typeof(ArgumentNullException))]
public void GenericFooNullArgumentInConstructor()
{
var foo = new Foo<int>(null);
}
//Is this test necessary?
[TestMethod]
[ExpectedExeption(typeof(ArgumentNullException))]
public void NonGenericFooNullArgumentInConstructor()
{
var foo = new Foo(null);
}
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()
{
var foo = new Foo<int>(null);
}
//Is this test necessary?
[TestMethod]
[ExpectedExeption(typeof(ArgumentNullException))]
public void NonGenericFooNullArgumentInConstructor()
{
var foo = new Foo(null);
}
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
是的。无需查看所有实现，这是验证派生类是否维护了基类的保证的最简单方法。特别是当实习生鲍勃稍后进来并修改您的派生类以执行其他操作时。
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.
一言以蔽之：是的。
这里的关键是回归 - 你需要编写单元测试来验证你当前的实现（甚至如果您是 TDD，则在实现之前），但您编写它也是为了保护自己免受将来代码的破坏性更改。
由于基类和子类将来都可能发生更改 - 都应该进行测试。
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.
这取决于...
你为什么要编写单元测试？
1) 测试您将要编写的代码
2) 测试您已经编写的代码
3) 测试其他人将来可能编写的代码
如果您正在编写代码来测试您将要编写的内容，请编写它满足您要编写的代码的要求。
如果您正在编写测试来测试您的代码，请测试您编写的代码。
如果您编写测试是为了防止其他人更改您的代码，那不是您的责任。
示例
您有一个带有特定方法 M 的基类 A。您已经向后、横向和颠倒测试了该方法。然后，您创建 A 的 3 个子类，并将它们称为 B、C 和 D。您为 B 类和 C 类添加新的功能内部方法。
您应该测试 B 类和 C 类的新方法，因为此代码未经测试，但A 类的方法 M 已经经过测试。
您重写类 D 中的方法 M，添加代码，然后调用基方法 M。应该测试新的重写方法，并且必须将其视为全新的方法。单元测试无法确认基类的M方法是否被调用。
写四次同样的测试对任何人都没有任何好处。每个开发人员都应该为他们编写的代码重写测试。如果该代码经过测试，并且测试满足要求，并且测试通过，那么该代码就是好的。
连续参加三次相同的考试是没有意义的。
另一方面
我们并不生活在一个完美的世界，如果您对其他开发人员没有测试自己的代码有疑问，那么您可能会发现以下内容很有用：为他们做他们的工作。但请注意，测试他们编写的代码不是您的工作，而是他们的工作。
超级晚更新...
您还应该测试将直接受您正在编写的新代码影响的方法。例如，如果您不更改方法A，但方法A依赖方法B，并且您覆盖方法B，则您应该考虑测试派生类中的方法 A，因为方法 A 的功能可能由于它依赖于方法 B 而发生了更改。
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).