Java 编写junit测试来处理继承问题

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

我们有一组从抽象基类继承的类。继承有好几层（基础->A、B、C->C1、C2、C3->C3-1等）。有时，有人重写一个类（类a）的方法，该类有几个子类。但正因为如此，我们在A班的呼叫儿童班上得到了糟糕的结果

所以，我正在寻找解决方案，试图防止这种情况，并创建一个测试框架来处理这种情况

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

还有，我和一个人谈过，他说可能已经有图书馆在做这件事了

---

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

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

通过修复坏设计来修复坏设计

换句话说：OO首先要理解的是（Liskov替换原理）。换句话说：当您的开发人员在继承树的“中间”更改了某些内容，并导致更底层的子类中出现意外行为时，您应该在教育和设计会话中进行投资

除此之外，您不需要特定的测试。当对公共类的所有公共方法进行彻底测试时，您应该很快发现此类问题。但是没有办法从语法上确定你对所有课程都有良好的测试。一些方法X有n种测试方法，这一事实证明了这一点。。。没有说明任何测试方法的质量。知道你有“足够”的测试是没有帮助的。。。但遗憾的是，有一半的测试没有进行正确的检查/验证；因此，它们一直在流逝

---

长话短说：你现在看到的是一个问题。你的问题是“当我们弄乱代码时，我们的测试不会失败”。但你的X问题是：你首先创造了一个糟糕的设计；现在你正在寻找解决这个问题的方法。从长远来看，这根本行不通。

为什么您认为需要一些特殊的反射测试框架？你只需要测试。如果有人修改了一些破坏现有功能的东西，那应该被看作是一种回归。为什么重构不是一种选择呢？@luk2302 b/c这是每一寸代码都要用到的。@jornsharpe这就是我要做的。我需要强迫人们为每一级继承编写测试。否则，就没有意义了。然后开始报告测试覆盖率。我希望得到这样的答案。他非常欢迎你。虽然我有一种模糊的感觉，OP对此不会太高兴。@GhostCat我没有生气，我不高兴。我只是想处理眼前的情况。在一个完美的世界里，我们都会编写测试、进行代码审查和重构，并拥有一个漂亮的代码库。不幸的是，这里的情况并非如此。在这种情况下，我正试图充分利用我对代码库所能做的。@ST As说：关键是你可以自动“构造”（生成）测试用例。在这里唯一有帮助的是为你的每个孩子班级进行良好的测试；这样你至少可以注意到，当一些C因为A被改变而中断时。