为什么我要使用MockRunner而不是普通的/手动的依赖注入？

Question

在我们的公司，我们有一个服务层，它接受一些请求XML，通过JDBC访问各种存储的进程(SP)，处理数据并用一些响应XML进行响应。最近，人们开始在他们的JUnit测试中采用MockRunner来模拟来自SP的响应。使用MockRunner设置来自SP的模拟响应的代码看起来很糟糕(这是我打开的第一个随机测试类)：

    MockConnection connection = new MockConnection();
    MockContextFactory.setAsInitial();
    InitialContext context = new InitialContext();
    context.rebind(READ_PAYMENT_DATA_SOURCE, getDS());
    getDS().setupConnection(connection);
    m_csStatementHandler = connection.getCallableStatementResultSetHandler();
    m_csStatementHandler.clearResultSets();
    m_csStatementHandler.clearCallableStatements();
    m_csStatementHandler.setExactMatch(false);
 m_csStatementHandler.prepareReturnsResultSet(READ_PAYMENT, true);
    m_csStatementHandler.setExactMatch(false);
    m_csStatementHandler.setExactMatchParameter(false);
    Map parameterMap = new HashMap();
    parameterMap.put(new Integer(1), null);
    parameterMap.put(new Integer(2), null);
    parameterMap.put(new Integer(3), null);
    parameterMap.put(new Integer(4), null);
    m_csStatementHandler.prepareOutParameter(READ_PAYMENT, parameterMap);
    //Set up the cursor of applications for return.
    MockResultSet resultApps = m_csStatementHandler.createResultSet();  

    resultApps.addRow(getPaymentSchedule("E", "Monthly", new Short("1"),null,null,null,null,null,null,null));
    resultApps.addRow(getPaymentSchedule("A", "Weekly", new Short("1"),null,null,null,null,null,null,null));
    resultApps.addRow(getPaymentSchedule("R", "Yearly", new Short("1"),null,null,null,null,null,null,null));
    resultApps.addRow(getPaymentSchedule("S", "Weekly", new Short("1"),null,null,null,null,null,null,null));
    resultApps.addRow(getPaymentSchedule("W", "Monthly", new Short("1"),null,null,null,null,null,null,null));

    MockResultSet[] results = new MockResultSet[1];
    results[0] = resultApps;
    m_csStatementHandler.prepareResultSet(READ_PAYMENT, resultApps);   

由于许多原因，上面的代码很糟糕，但它确实清楚地显示了从存储过程设置响应的复杂性和开销。

到目前为止，我一直在使用手动依赖注入来注入实际调用存储过程的类。我所要做的就是创建一个模拟的SP调用者类(负责SP的实际执行)并设置我想要的响应数据。我对这种技术非常满意，而且它比上面的技术简单得多，因为它专注于数据，而不是担心实现细节。但我的问题是，你什么时候想要使用MockRunner？它似乎对单元测试有些过分，所以我猜它更多的是用于集成测试还是系统测试？即使这样，我仍然觉得使用DI框架交换SP调用者类比为每个存储过程调用设置上面的所有代码更容易。请多多指教！谢谢

Answer 1

最终，您将研究mocking背后的一般哲学。我会给你我的两个观点，但我也会向你推荐任何主要的模拟库，这些库可能会为它们自己的存在提供很好的理由。以Mockito为例。

测试/模拟社区通常会区分手动操作(通常称为“存根”(Stub)(静态的手写类)和“模拟”(Mock)(动态的、运行时生成的类)。

与仅使用stubbing相比，mocking的好处非常大。许多测试人员对仅仅为了测试而编写接口实现和/或具体类的子类的想法感到恼火。要做到这一点，通常需要实现所述类/接口的所有方法，即使您只想测试特定的方法。

Mocking让您可以通过定义您想要为其提供行为的方法来解决这个问题，这是非常强大的。此外，模拟允许您从一个测试更改到下一个测试的行为。要使用存根实现这一点，您必须编写一个全新的存根类。

不同的模仿库的语法略有不同。有些你可能会觉得比其他的更具可读性。我目前最喜欢的是Mockito，因此有了早期的参考，但它们会随着时间的推移而发展。可能有必要确定您的组织为什么使用现有的mocking套件，以及另一个套件是否仍然可以满足您的需求，并且更具可读性。

希望您的测试编写人员能够将通用行为引入到测试设置方法中(比如JUnit的@Before)，这样您就不必到处看到模拟创建和通用初始化。