如何为复杂的底层实体编写测试用例？

我正在为现有系统编写单元测试用例。底层类的体系结构本身非常复杂。如何为复杂的底层实体编写测试用例？

Blockquote RequestHanndler ==> processes ==> Order ===>依赖于==>服务层==连接到==> DB层。

我正在为RequestHandler写一个测试用例。测试方法（doProcess()）创建Order类的新实例。 Order类本身对服务层的依赖非常紧密。我想创建一个原子测试用例，所以不会执行任何其他代码层。

什么应该为这些scenrios创建测试用例的最佳过程？

2011-11-07 Vijay Shanker Dubey

“Order类本身所具有的业务层上非常紧张的依赖。” - 为什么？ – blank

@Bedwyr这不是我的设计。这就是这样，我没有任何控制权。 –

当你想为紧密耦合的代码编写单元测试时，它可能会有点复杂。为了使uni测试更容易，您应该更好地依赖抽象，而不是真正的实现。例如。 Order类应该不依赖于服务层的实际实现，而应该引入一个更容易模拟的接口，而不是可能设置为final的类。

由于您的RequestHandler负责创建订单实例，因此您必须提供一种在单元测试中模拟订单类的方法。简单的方法是创建一个简单地创建一个新订单实例的受保护方法。

protected Order createOrder(String someParam) { 
    return new Order(someParam); 
}

在您的单元测试中，您现在可以扩展该类并覆盖工厂方法。使用Mockito这看起来像：

protected Order createOrder(String someParam) { 
    Order order = Mockito.mock(Order.class); // create mock object 
    // configure mock to return someParam when 
    // String Order#getSomeParam() gets invoked 
    Mockito.doReturn(someParam).when(order).getSomeParam(); 
    return order; 
}

来源

2011-11-07 08:36:53

这种系统的单元测试的典型方法是嘲弄。有几个Java模型框架。我个人使用EasyMock，但也有其他人。

所以，我认为你应该尝试首先测试请求处理程序的逻辑。您应该模拟订单（即使用模型框架创建虚拟，而不是实际的订单实例）。当测试这个图层时会更深入并开始测试内部图层。

其他策略是从下往上，即先测试内层。这种策略可能是“正确的”，但它不会让你的经理获得快速的结果，因为管理者通常喜欢看到“大”的图景，很少进入细节。

底线：祝你好运。

来源

2011-11-07 08:23:17 AlexR

我想创建一个Order类的模拟版本，但我无法确定任何让RequestHandler使用MockedOrder的方法。请建议。 –

如何为复杂的底层实体编写测试用例？

回答

相关问题