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

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

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

使用抽象类的主要动机之一是在应用程序中启用多态性——即:您可以在运行时替换不同的版本。事实上，这与使用接口非常相似，只是抽象类提供了一些常见的管道，通常称为模板模式。

从单元测试的角度来看，有两件事需要考虑:

抽象类与相关类的交互。对于这种情况，使用模拟测试框架是理想的，因为它表明您的抽象类可以很好地与其他类协作。 派生类的功能。如果您为派生类编写了自定义逻辑，则应该单独测试这些类。

编辑:RhinoMocks是一个很棒的模拟测试框架，它可以通过动态地从您的类派生在运行时生成模拟对象。这种方法可以为您节省大量手工编写派生类的时间。

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

 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.

       }

   }

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

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

严格来说，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).

如果您的抽象类包含具有业务价值的具体功能，那么我通常会通过创建一个测试双存根来直接测试它，或者使用一个模拟框架来为我做这件事。我选择哪一个很大程度上取决于我是否需要编写抽象方法的特定于测试的实现。

我需要这样做的最常见的场景是当我使用模板方法模式时，例如当我正在构建某种将由第三方使用的可扩展框架时。在本例中，抽象类定义了我想要测试的算法，因此测试抽象基类比测试特定实现更有意义。

然而，我认为重要的是这些测试应该只关注真实业务逻辑的具体实现;您不应该单元测试抽象类的实现细节，因为您最终会得到脆弱的测试。