java - 编写junit测试来处理继承 hell

Question

我希望向我们的代码库添加一些 junit。

我们有一组从抽象基类继承的类。继承是多层的(Base-> A、B、C -> C1、C2、C3-> C3-1 等)。有时，有人会重写具有多个子类的类(A 类)的方法。但正因为如此，我们在A类的征召 child 类得到了不好的结果。

因此，我正在寻找能够尝试防止这种情况并创建一个测试框架来处理这种情况的解决方案。

我最初的想法是，我们需要创建一个 TestSuite，它需要通过反射检查 TestClass 是否为基类中的每个方法至少有 1 个测试用例。这将确保在中级类中添加重写方法的人知道他们的更改将影响子类。

另外，我正在和某人交谈，他说可能已经有图书馆可以做到这一点。

我正在寻找如何编写测试来处理这种情况的想法和示例。在这种情况下，重构不是一个选择。

Answer 1

抱歉，对于糟糕的设计，正确的答案不是通过提出“有趣的”单元测试来“修复”它。

通过修复糟糕的设计来修复糟糕的设计。

换句话来说:关于 OO，首先要理解的是 LSP (里氏替换原则)。换句话说:当您的开发人员更改了继承树“中间”的某些内容，并导致进一步的子类出现意外行为时，那么您应该投资于教育和设计类(class)。

除此之外，您不需要特定的测试。当您的公共(public)类的所有公共(public)方法都经过彻底测试后，您应该很快就能发现此类问题。但无法从语法上确定您对所有类(class)都有良好测试。事实上，某些方法 X 有 n 个测试方法...并不能说明任何测试方法的质量。知道您有“足够”的测试并没有帮助……但抱歉，不幸的是，一半的测试没有进行适当的检查/验证；因此它们一直在流逝。

长话短说:您正在查看 XY问题在这里。你的 Y 问题是“当我们搞乱代码时，我们的测试不会失败”。但你的 X 问题是:你一开始就创建了一个糟糕的设计；现在你正在寻找解决这个问题的方法。从长远来看，这根本行不通。