单元测试架构问题

Question

因此，我开始为以下代码布局单元测试：

public interface MyInterface {
  void MyInterfaceMethod1();
  void MyInterfaceMethod2();
}

public class MyImplementation1 implements MyInterface {
  void MyInterfaceMethod1() {
    // do something
  }

  void MyInterfaceMethod2() {
    // do something else
  }

  void SubRoutineP() {
    // other functionality specific to this implementation
  }
}

public class MyImplementation2 implements MyInterface {
  void MyInterfaceMethod1() {
    // do a 3rd thing
  }

  void MyInterfaceMethod2() {
    // do something completely different
  }

  void SubRoutineQ() {
    // other functionality specific to this implementation
  }
}

有几种实现，并且期望有更多实现。

我最初的想法是节省自己用类似这样的东西重写单元测试的时间：

public abstract class MyInterfaceTester {
  protected MyInterface m_object;  

  @Setup
  public void setUp() {
    m_object = getTestedImplementation();
  }

  public abstract MyInterface getTestedImplementation();

  @Test
  public void testMyInterfaceMethod1() {
    // use m_object to run tests
  }

  @Test
  public void testMyInterfaceMethod2() {
    // use m_object to run tests
  }
}

然后我可以轻松地对其进行子类化以测试特定于实现的附加方法，如下所示：

public class MyImplementation1Tester extends MyInterfaceTester {
  public MyInterface getTestedImplementation() {
    return new MyImplementation1();
  }

  @Test
  public void testSubRoutineP() {
    // use m_object to run tests
  }
}

同样对于实现 2 以后的方法。

所以我的问题实际上是：有什么理由不这样做吗？ JUnit 似乎很喜欢它，并且它满足了我的需求，但我在我读过的任何单元测试书籍和示例中都没有真正看到过类似的东西。

我是否无意中违反了一些最佳实践？我是否正在为未来的心痛做好准备？难道还有我没有考虑过的更好的出路吗？

感谢您的任何帮助。

Answer 1

有什么理由不这样做吗？

不，做吧。测试正是出于这个原因而形成的类。

我在我读过的任何单元测试书籍和示例中都没有真正看到过类似的内容。

继续阅读。介绍不包括这一点。

我是否无意中违反了一些最佳实践？

不。

我是否会让自己在未来的道路上心痛？

不。

有些人对“脆弱的测试”感到紧张。您可以在这里找到一些问题，寻找实现这一点的方法，以便对软件的更改不会导致测试的更改。从长远来看，尝试创建“稳健”的测试是愚蠢的。您希望编写测试，以便对软件的可见界面级别进行的每一个微小更改都需要重写测试。

您需要进行测试，以便看不见的内部更改不需要重写测试。

类和子类的使用与这些考虑因素是正交的。

是否还有我没有考虑过的更好的出路？

不。面向对象才是重点。正是出于这个原因，测试成为一类。

Answer 2

虽然我 100% 支持 SLott 我也会考虑 JUnit 参数化测试而不是测试类层次结构：

@RunWith(Parameterized.class)
public class MyInterfaceTester {
  private MyInterface m_object;  

  public void MyInterfaceTester(MyInterface object) {
    m_object = object;
  }

  @Parameters
  public static Collection<Object[]> data() {
    List<Object[]> list = new ArrayList<Object[]>();

    list.add(new Object[]{new MyImplementation1()});
    list.add(new Object[]{new MyImplementation2()});

    return list;
  }

  @Test
  public void testMyInterfaceMethod1() {
    // use m_object to run tests
  }

  @Test
  public void testMyInterfaceMethod2() {
    // use m_object to run tests
  }
}

不需要测试类层次结构：只需通过在 data 方法中添加另一个列表元素来添加新的实现。

Answer 3

如果您确实在每个测试类中进行相同的设置和拆卸，那么您所做的就很好，但我发现在实践中几乎从未出现过这种情况。事实上，大多数时候，像这里这样的实例化测试数据的设置方法甚至不是您想要的。相反，在测试类中，您可以设置任何基础结构，并且每个测试方法都设置自己的对象实例来测试它的某些方面。