首先，如果抽象类包含一些具体的方法，我认为你应该这样做，考虑这个例子

 public abstract class A 

 {

    public boolean method 1
    {
        // concrete method which we have to test.

    }


 }


 class B extends class A

 {

      @override
      public boolean method 1
      {
        // override same method as above.

      }


 } 


  class Test_A 

  {

    private static B b;  // reference object of the class B

    @Before
    public void init()

      {

      b = new B ();    

      }

     @Test
     public void Test_method 1

       {

       b.method 1; // use some assertion statements.

       }

   }

我为抽象类和接口所做的工作如下:我编写一个测试，将对象作为具体对象使用。但是在测试中没有设置类型为X的变量(X是抽象类)。这个测试类并没有添加到测试套件中，而是它的子类，它们有一个setup-方法，将变量设置为x的具体实现。这样我就不会重复测试代码。如果需要，未使用测试的子类可以添加更多的测试方法。

如果抽象类适合于您的实现，则测试(如上所述)派生的具体类。你的假设是正确的。

为了避免将来的混乱，请注意这个具体的测试类不是模拟的，而是假的。

严格来说，mock由以下特征定义:

A mock is used in place of each and every dependency of the subject class being tested. A mock is a pseudo-implementation of an interface (you may recall that as a general rule, dependencies should be declared as interfaces; testability is one primary reason for this) Behaviors of the mock's interface members -- whether methods or properties -- are supplied at test-time (again, by use of a mocking framework). This way, you avoid coupling of the implementation being tested with the implementation of its dependencies (which should all have their own discrete tests).

编写一个Mock对象，并仅用于测试。它们通常是非常非常小的(继承自抽象类)，而不是更多。然后，在你的单元测试中，你可以调用你想测试的抽象方法。

您应该测试包含一些逻辑的抽象类，就像您拥有的所有其他类一样。

我反对“抽象”测试。我认为测试是一个具体的概念，没有抽象的概念。如果您有公共元素，请将它们放在辅助方法或类中供所有人使用。

至于测试抽象测试类，一定要问自己要测试的是什么。有几种方法，您应该找出适合您的场景的方法。您是否试图在子类中测试一个新方法?然后让您的测试只与该方法交互。测试基类中的方法吗?然后可能只针对该类有一个单独的fixture，并使用尽可能多的测试单独测试每个方法。

如果具体方法调用任何抽象方法，该策略将不起作用，您将希望分别测试每个子类的行为。否则，只要抽象类的具体方法与子类解耦，就可以像您所描述的那样扩展它并存根抽象方法。