你应该如何为同一个接口的多个实现编写junit测试用例？

在提问之前,让我解释一下当前的设置:

我有一个服务接口,比如Service,还有一个实现,比如说ServiceImpl.此ServiceImpl使用其他一些服务.所有服务都是春天加载的bean.

现在,我想为ServiceImpl编写junit测试用例.同样,我使用applicationContext来获取Service bean,然后在其上调用不同的方法来测试它们.

对于公共方法看起来都很好但是如何为私有方法编写测试用例？因为我们可能没有相同的私有方法用于不同的实现？

任何人都可以在这里帮助我编写测试用例的首选方法吗？

纯粹的答案是私人方法被称为有原因!;-)

转过来问题:只给出(可公开访问的)界面的规范,在编写代码之前如何布置测试计划？该接口描述了实现它的对象的预期行为 ; 如果在那个级别上无法测试,那么设计就会出现问题.

例如,如果我们是运输公司,我们可能会有这些(伪编码)接口:

CapitalAsset {
    Money getPurchaseCost();
    Money getCurrentValue();
    Date  whenPurchased();
    ...
}

PeopleMover {
    Weight getVehicleWeight();
    int    getPersonCapacitly();
    int    getMilesOnFullTank();
    Money  getCostPerPersonMileFullyLoaded(Money fuelPerGallon);
    ...
}

并且可能包含以下类:

Bus implements CapitalAsset, PeopleMover {
    Account getCurrentAdvertiser() {...}
    boolean getArticulated() {...}
    ...
}

Computer implements CapitalAsset {
    boolean isRacked() {...}
    ...
}

Van implements CapitalAsset, PeopleMover {
    boolean getWheelchairEnabled() {...}
    ...
}

在设计CapitalAsset理念和接口,我们应该来与财务家伙协议对如何任何的情况下CapitalAsset应该做的.我们会针对CapitalAsset这种情况编写测试,仅依赖于该协议; 我们应该能够在Bus,Computer等等上运行这些测试Van,而不依赖于涉及哪个具体类.同样地PeopleMover.

如果我们需要测试一些Bus独立于一般合同的东西CapitalAsset,PeopleMover那么我们需要单独的总线测试.

如果一个特定的具体类具有如此复杂的公共方法,以至于TDD和/或BDD无法干净地表达其预期行为,那么,再一次,这是一个有问题的线索.如果在具体的类中有私有的"帮助"方法,那么它们应该出于特定的原因; 应该可以问一个问题"如果这个助手有缺陷,哪些公共行为会受到影响(以及如何)？"

对于合法的,固有的复杂性(即来自问题域),类可能适合具有辅助类的私有实例,这些辅助类承担特定概念的责任.在这种情况下,辅助类应该可以单独测试.

一个好的经验法则是:

如果测试太复杂,那就太复杂了!