这是一个典型的测试案例,显示了设计中的潜在缺陷。您不能嘲笑,
JodaTime因为您在被测类中对这些类有硬性依赖。
看一下SOLID原理以了解为什么这可能是个问题(尤其是在这种情况下是Dependency Inversion
Principle)。如果您将
JodaTime某个地方作为依赖项注入,那么在单元测试中,您可以根据需要用模拟,存根或间谍替换它的真实实例。
但是:
JodaTime在生产环境中,无论使用寿命多长,这种东西极不可能注入其他任何东西。取而代之的是,在这种情况下,使用组合方法设计模式可能会更好。在这里,您将提取用于生成的任何计算/算法,并将其转换
printjobName为另一种方法(由于您的代码段从未为该变量分配值,因此我在这里看不到如何做)。然后,您可以监视(部分模拟)您的被测类,以仅模拟该方法并返回固定值,而与
JodaTime传递的实际日期时间无关,例如:
public class PrintProcessor { ... public String getPrintJobName(Shipper shipper) { String printJobName = null; String timeHash = this.getTimeHash(); if (this.isBeforeFourPM()) { switch(shipper) { printJobName = // Do something with timeHash to generate name } } else { ... } return printJobName; } public boolean isBeforeFourPM() { return (jodaTime.getCurrentDateTimeEST().isBefore(jodaTime.getFourPM_EST()) || jodaTime.getCurrentDateTimeEST().isAfter(jodaTime.getSevenPM_EST())); } public String getTimeHash() { ... // Do something to hash the time value in to a String }}
现在您可以在测试中编写:
@Testpublic void testGetPrintJobNameBeforeFourPM() { PrintProcessor concretePrintProcessor = new PrintProcessor(); PrintProcessor printProcessor = spy(concretePrintProcessor); doReturn(true).when(printProcessor).isBeforeFourPM(); String printJobName = printProcessor.getPrintJobName(Shipper.X); assertEquals("XNCRMNCF", printJobName);}
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)