这部分是对this question的跟进。
我不确定最好的方式来问这个，所以我会尝试一个简短的故事来设置场景：
曾几何时，有一个类'A'，它有一个单元测试类'ATests'负责通过公共接口测试它的行为。他们幸福地在一起生活了一段时间然后发生了变化，并且“B”级出现了，因为它与“A”级有很多共同之处，所以引入了一个基类。
A类的测试已经涵盖了基类的公共行为。那么问题是接下来会发生什么？
•B类是否需要对公共（基类行为）进行测试？看起来行为是B的一部分，所以应该进行测试，但这些测试是否应该与A类共享？对于基类？如果是这样，分享的最佳方式是什么？
•新基类是否需要单元测试，或者基类是否可以通过子项测试进行测试？基类是抽象的是否重要？
•确保课程A＆amp; B派生自基类并“信任”基类的单元测试以测试常见行为（因此测试不需要在子类中复制）？ A＆amp; A的测试B只需要测试它们是新的/改变的行为吗？
•我是否遵循完全错误的方法，每个真实班级大约有一个单元测试课程？
我在不同的时间采取了不同的观点，不同的方法会对重构代码的能力，编写测试的时间等产生相当大的影响。人们发现哪些方法效果最好？
答案 0 :(得分：4)
就个人而言，考虑到时间，我倾向于测试所有三个（基础和两个派生）。它表明您不是无意中重写了基本方法并改变了它们的行为，并且您继承的类仍然提供了预期的语义。如果行为确实没有改变，那么它可以像复制粘贴作业一样简单，但它提供了更完整的覆盖。
请注意“给定时间”部分。如果时间是一个问题（并且总是如此），那么测试基类或继承的功能可能是较低的优先级。但是测试对自己来说是非常好的接种，并且在以后进行重构时会让你更加自信，所以你只是通过不像你有时间那样做完整的覆盖来缩短你自己，你的客户和/或你的维护者。
但是，如果你有专门的测试人员或QA团队，那么重复这样的重复事情是完全可以接受的。但有时给他们买啤酒:-)他们让你看起来更好！
答案 1 :(得分：3)
您可以查看代码覆盖率工具;他们可以告诉你，如果你真的测试了所有的代码。就个人而言，如果我有一个覆盖基类行为的测试，并且我没有覆盖它，我将不再测试它。目标是让代码更改（可能）只打破一个测试。
不觉得每个真实班级需要坚持一个单元测试课程。每个独特的设置夹具一个单元测试类是单向的，然后是整个BDD学校......
答案 2 :(得分：0)
重构测试代码与重构生产代码同样重要。两者都应被视为一等公民。因此，如果要将公共方法提取到基类，那么它应该有自己的一组测试。如果您的测试用例设计得恰当，每个测试都测试一件事，那么测试重构应该很容易。
如果您正在提取受保护的功能，那么它可能是一个略带灰色的区域。如果测试方法对于类是新的，那么我希望它们在派生类中进行测试，因为它们可能在那里使派生类正常运行。理想情况下，这应该保持最小，因为基类功能变得不那么明显。
派生类然后将在其自己的测试集中测试剩余的公共方法。
如果你更改了生产代码而不是测试，那么你应该加入一个覆盖工具，这样你就可以对你的测试足够有信心。