Java 为什么通过扩展类来测试类被认为是一种不好的做法？

据我所知，测试一个类有两种主要方法

测试类以扩展被测试的类

测试类以创建被测试的类（合成）

据我所知，第一种方法被认为是一种不好的做法

---

但为什么呢？

对我来说，单元测试有两个主要目的：

验证testobject正在执行我期望它执行的操作

记录如何正确使用测试类

通过扩展被测试类，测试接缝可能会改变类的行为。这是一种不好的测试方法。 有时我甚至会这样做来修复当前时间依赖关系，例如，如果DI不是选项：

   private InstanceToTest instance;
   private Calendar now = new GregorianCalendar(2019, 4, 4, 13, 23, 47);
   @Before
   public void initInstance() {
      instance = new InstanceToTest() {
         @Override
         Calendar getNow() {
            return now;
         }
      };
   }

现在我可以在2019年4月4日13:23:47进行测试，以使测试稳定

---

有时我想分别测试提取的内部方法。我更喜欢将这些方法包设置为私有。这样，我就可以从测试中调用它们（如果它与测试源文件夹中的包在同一个包中），而不会覆盖它们。

类

FooTest

的实例不需要是

Foo

的实例。在任何情况下都不应该使用

FooTest

的实例来代替

Foo

@AndyTurner的实例，一个优点可能是公开受保护的方法，但我想这也被认为是一种不好的做法（测试受保护的方法）UnitTest验证被测代码的公共可观察期望行为。“公共”是指其他生产代码调用此方法。这并不意味着被测代码通过

public

annotated方法公开这种行为，但通常是这样。关于私有/受保护等的测试。内容：单元测试是关于发现bug的。实现中存在bug-不同的实现，不同的可能bug。将斐波那契函数视为迭代/递归函数、闭式表达式（Moivre/Binet）、查找表：接口总是相同的，可能的错误明显不同。此外，在查看覆盖率时，您总是查看实现，而不是接口。如何设计类，以便真正能够测试实现细节，则是另一回事。。。