我有一个带有评估方法的订阅类。 这种方法得到了这个订阅的计划（作为模型），然后这将获得它的费用。 通过这种方式，订阅构建一个发票对象，其中包含从上次结算日期开始计费的费用。
我想测试这个方法，但在我看来，这不是一个单元测试，因为它会涉及许多具有不同依赖关系的对象。
您如何测试此方法？
答案 0 :(得分：10)
它不是纯粹主义者的单元测试（而是集成测试），但它仍然可以是一个非常好的测试:-)从技术上讲，你可以用JUnit（或者你最喜欢的）运行它单元测试框架是），所以恕我直言，区别仅在于术语。
如果从头开始编写代码，最好首先单独编写单个方法的单元测试（模拟出依赖关系），然后在下一阶段添加更高级别的集成测试，例如你描述的那个，验证您的课程能够很好地协同工作。
但是，在遗留项目中（即大量未经测试的继承代码），从细粒度的低级单元测试开始通常是不可行的;相反，编写更高级别，更复杂的测试更有效，这些测试澄清并“锁定”更大组件的行为。
不幸的是，到目前为止，这个行业的大多数项目都是遗产:-(对我来说，在这些情况下，pragmatism赢得了接近纯度的方法： - ）
答案 1 :(得分：2)
目前看来这听起来像是集成测试，而不是单元测试。
如果要对所涉及的方法进行单元测试，则应该模拟依赖项（因此使用模拟发票来返回已知数据）。然后，您可以单独编写单元测试以确保发票类工作。