Question

单元测试适用于维护软件，特别是如果维护人员对整个系统不是很熟悉的话。

但我在这里有一个问题：

在我完成整个软件系统之前，我应该如何确定我需要编写单元测试的功能？换句话说，单元测试的最佳粒度是多少？

更糟糕的是，测试函数的名称或功能可能会在开发过程中或在时间重构之后发生变化，我应该如何维护单元测试？

Answer 1

我应该如何确定需要为哪个函数编写单元测试？

很简单：尝试尽可能地进行单元测试，并尝试尽可能高地获得单元测试覆盖率。当然，有些东西不可能进行单元测试（访问特定的硬件或数据库），有些东西不应该进行单元测试（第三方库的功能）。

什么是单元测试的最佳粒度？

如上所述，尽量让单元测试覆盖率尽可能高。更高=更好。

测试功能的名称或功能可能会在开发过程中或在时间重构之后发生变化，我应该如何维护单元测试？

将单元测试视为代码的一部分，并使用代码进行维护。当代码更改时，更改单元测试（修改，添加和删除所需的内容）以使它们通过，并且如果可能的话增加单元测试覆盖率。

Answer 2

TDD最容易入手。它说：除非你有一个下降的测试，否则永远不要写任何生产代码。所以无论何时你想写一段生产代码，都要停下来。并考虑该代码的合同应该是什么。然后写一个测试来检查合同是否有效。测试将无法编译，因为您没有代码 - 所以您有一个红色测试。现在你可以编写代码

了

所以当你想要创建一个计算器时，你要编写一个测试：

int result = new Calculator().add(4,3);
assertThat(result).isEqual(7);

现在您知道应该编写什么代码

关于测试维护：测试是一等公民，就像您的生产代码一样。你必须像生产代码一样维护和重构它们。 IDE有助于实现

Answer 3

从语用上讲，您必须首先测试您的类外部接口（公共方法）。你必须指出＆＃34; heavy＆＃34;使用并提供最佳的覆盖范围。通常，您应该尽量避免大幅更改类接口以确保向后兼容性并允许您的代码轻松更改/重构。因此，适当的测试用例可能也会保留下来。