1

在我们的一个服务类中，我有一堆方法，它们只返回 DAO 结果而没有像这样的处理

public void acceptRequest(User from, User to) {
    rosterDAO.acceptRequest(from, to);
}

此方法的单元测试如下所示

private final RosterDAO rosterDAO = context.mock(RosterDAO.class);
...
public void testAcceptRequest() {
context.checking(new Expectations() {{
    oneOf (rosterDAO).acceptRequest(from, to);
    will (returnValue(1));
}
});

现在对我来说，这个测试看起来完全没有意义，它唯一做的就是测试该方法是否调用了另一个方法。DAO 测试已经很好地覆盖了返回值。我很想放弃这些测试，因为我认为没有足够的继续来保证维护它们的努力。

因此，对于坚持 100% 覆盖率的所有 TDD 专家：

你认为这个测试给项目带来了什么价值？

我怎样才能写得更好？

4

3 回答 3

3

经验法则是测试所有可能破坏的东西。因此，如果您确信单线在任何实际情况下都无法合理地破坏，那么不对其进行测试可能就可以了。但是，如果您已经对其中一些方法进行了工作单元测试，恕我直言，没有理由放弃它们 - 拥有更多的单元测试永远不会受到伤害，并且维护成本应该可以忽略不计。

事实上，该方法看起来很简单。但是，还要考虑未来扩展/修改的可能性- 在可预见的将来修改方法的任何真正机会都是一个足够强大的案例来保证现在进行单元测试。

不过，您可能希望通过集成测试覆盖更大的场景，以确保系统的不同部分作为一个整体在（接近）真实情况下按预期协同工作。

恕我直言，100% 的单元测试覆盖率在实际项目中几乎总是不切实际和不必要的。通常有相当多的异常处理代码，例如难以测试和微不足道的代码，因此根据我的经验，它可能不值得付出努力。首先关注最关键的部分，利用有限的资源获得最大的收益。如果像这样的方法是最有趣的未测试的代码部分，并且您仍然有时间和精力来涵盖它们，那么您也可以去完善您的测试套件 :-) 但是，恐怕大多数现实生活中的项目离这种困境还很远:-(

于 2010-09-23T08:28:25.660 回答
2

使这些测试变得有趣需要多少额外的复杂性？

这里有三件事可能是错误的：从您可能拥有的所有其他 DAO 中选择 rosterDAO，以及您传递的两个参数：from 和 to，例如可以在没有任何编译错误的情况下进行转置。碰巧你似乎没有异常处理要做（顺便说一句，对吗？），所以我同意这是一个非常小的情况。

但是，如果这里有一点额外的逻辑，例如选择 DAO 的任何条件或要通过哪些参数，那么我当然需要一些测试。

所以从大的角度看你的项目，这种方法是典型的吗？假设您有 20 种方法，其中 19 种确实具有条件，因此值得测试。在这种情况下，我只会让事情保持整洁并测试这种方法 - 几乎没有任何工作要做。

如果这是一种占主导地位的模式，那么我同意 Peter Torak 的观点，这可能不值得付出努力。但我会更加关注集成测试以涵盖这一领域。

于 2010-09-23T08:34:50.377 回答
1

创建此特定方法的单元测试可能毫无意义，因为其中没有验证或业务逻辑（验证可能在 rosterDAO 级别）。但是，您应该使用真正的 rosterDAO 而不是模拟的来创建该方法的集成测试。

于 2010-09-23T08:43:41.350 回答