Question

为这样简单的代码编写单元测试是否值得：

public class TableController {
  private TableView view;

  public TableController(TableView view) {
    this.view = view;
  }

  public void onShowTable() {
    view.showTable();
  }
}

我的项目中有很多非常简单的代码，它们连接控制器，视图，服务，远程服务等。单元测试只是重复所有内容，通常比代码本身更大：

public class TableControllerTest {
  @Test
  public void showTable() {
    TableView view = createMock(TableView.class);
    view.showTable();

    replayAll();

    TableController controller = new TableController(view);
    controller.onShowTable();

    verifyAll();
  }
}

真的需要这样的测试吗？

谢谢！

Answer 1

不需要对类似模块进行测试。但是，对这类模块的测试并不难写。所以写测试真的没什么坏处。您还必须记住，您所展示的那种简单模块随着时间的推移会逐渐成长。如果您没有对模块进行测试，那么当向模块添加新的逻辑位时，您可能会认为旧模块和新逻辑之间的增量太简单而无法测试。模块一点一点地增长而不进行测试。

所以最后，我会为简单的模块编写测试，因为它们编写起来很简单，并且当模块变得更复杂时它们充当占位符。

Answer 2

没有。您不必对所有内容进行单元测试。另一方面，您可能希望先尝试反转流程并编写测试，然后再编写代码。在许多情况下，您会发现，如果您先编写测试，那么在编写测试时应该是什么样的结果，而不是代码是什么时，您最终会编写您认为会考虑的不同代码。我应该写吗？以这种方式编写测试时，您会发现测试比简单地使用它们执行代码更有价值。一旦掌握了它，您还可以了解何时需要测试，何时不需要 - 例如，自动属性访问器不需要进行单元测试IMO。

如果您已经在进行测试，那么我不确定我是否理解这个问题，因为您的测试不能重复尚未编写的内容。您已经使用测试来定义方法应该执行的操作。这是一项非常有用的活动，并且在其他测试导致突破性变化的情况下也具有保护作用。在单元测试中比在实时应用程序中找到它要好得多。

Answer 3

当您更改方法的实现并且需要确保它仍然有效时，需要它们。当它发生在2年之后，试图记住该方法如何编写单元测试为时已晚 - 您现在应该这样做。

当您将它们与更复杂的方法/逻辑的测试进行比较时，它们不太需要，但仍需要它们。

Answer 4

不同的人会有不同的意见。你肯定需要测试一切可能出错的东西。这对你意味着什么取决于你。过度测试会降低生产力，因为太少的测试可能会遗漏问题。你需要确定什么对你有用。

Answer 5

我的项目中的
代码，用于连接控制器，视图，服务，远程服务等。

对于那种事情，单元测试可能没有用 - 但是集成测试是，即测试可以检查整个应用程序的功能（可能基于用例），并且最少使用模拟。这些需要更长的时间，并且不能贯穿所有边缘情况，但它们在揭示组件交互方式中的问题以及这种粘合代码中非常有价值。

Answer 6

测试总是一件好事，特别是如果您希望代码随着时间的推移而增长。在重构或对代码库进行重大更改后，能够检查旧功能是否仍然正常工作非常有用。

在您的具体情况下，我认为这些代码的功能太小，无法从测试和测试中受益，而showTable等练习会更有用。

Answer 7

我不会测试简单的委托方法。

有一句好话（虽然我不记得是谁来的）： “永远不要测试太容易破坏的东西......”

原始单元测试

7 个答案: