c#单元测试——应该在派生类中进行单元测试，而在基类中进行单元测试吗?

本文关键字：单元测试 基类 派生 | 更新日期: 2023-09-27 18:10:53

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) { }
}

基本上，我知道应该对泛型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);
}

c#单元测试——应该在派生类中进行单元测试，而在基类中进行单元测试吗?

是。无需查看所有实现，这是验证派生类是否维护了基类的保证的最简单方法。尤其是当实习生Bob后来进来修改你的派生类来做别的事情时。

一句话:是的。
这里的关键是回归——你会写单元测试来验证你当前的实现(如果你是TDD的话，甚至在实现之前)，但你也会写单元测试来保护你自己免受未来代码的破坏变化。由于基类和子类将来都可能被更改，因此都应该进行测试。

这取决于…

你为什么要写单元测试?

1)测试你要写的代码

2)测试你已经写好的代码

3)测试某人将来可能编写的代码

如果你写代码是为了测试你要写的东西，那就根据你要写的代码的需求来写。

如果你写测试来测试你的代码，测试你写的代码。

如果你写测试是为了防止别人修改你的代码，那不是你的责任。

你有一个基类a和一个特定的方法m。你测试了这个方法的前后、侧面和上下。然后创建A的3个子类，分别称为B、C和d。为类B和C添加新的功能内部方法。

你应该测试B类和C类的新方法，因为这段代码是未经测试的，但是A类的方法M已经测试过了。

您在类D中重写方法M，添加代码，然后调用基方法M。新的重写方法应该经过测试，并且必须将其视为一个全新的方法。单元测试无法确认基类的M方法是否已被调用。

同样的测试写4次对任何人都没有好处。每个开发人员都应该为他们编写的代码重写测试。如果代码经过测试，并且测试满足需求，并且测试通过，那么代码就是好的。

同一个考试连续考三次是没有意义的。

另一方面

我们不是生活在一个完美的世界里，如果你对其他开发人员而不是测试他们自己的代码有问题，那么你可能会发现为他们做他们的工作很有用。但是要意识到，测试他们写的代码不是你的工作，那是他们的工作。

超迟更新…

您还应该测试方法，这些方法将直接受到您正在编写的新代码的影响。例如，如果您没有更改方法A，但是方法A 依赖于方法B，并且您重写了方法B，那么您应该考虑在派生类中测试方法A，因为方法A的功能可能由于依赖于方法B而发生了更改。

您也应该为派生类编写单元测试!单元测试可确保被测试的类按预期工作。这给了你重构它的机会。如果这样，在重构派生类的构造函数时就会犯错误——没有单元测试会发现这个错误。(如果您没有为派生类编写单元测试)。

相关文章：