unit-testing - 我应该什么时候设计和记录我的测试用例？

Question

在 SDLC 中，测试程序应在实施后立即进行。但是，测试驱动开发鼓励我们在执行时进行测试。在我的讲座课程中，教授说测试用例应该是设计的一部分。

我是一名初级开发人员，要实现一个新功能，我应该什么时候设计和记录我的测试用例？

我发现在完成实现之后对所有的案例都进行测试是不太实际的。这是因为一旦案例失败，我必须更改代码并重新测试所有案例。还有其他方法可以克服和避免这种情况吗？我知道自动化测试是解决方案之一，但不知何故，自动化测试不能激发所有的测试用例，尤其是涉及不同方的集成测试用例。

另外，在我的测试用例中，我应该测试代码的所有部分吗？或者只是测试该功能请求的功能？或者这实际上取决于你有多少时间？

非常感谢。

score 5 · Accepted Answer

您的问题并不容易回答，因为正如您所说，“这实际上取决于您有多少时间。” 不过，这里有一些意见：

实施后测试： 否

作为程序员，您是一种昂贵且稀缺的资源，多个截止日期叠加在一起。如此有效，这意味着“从不测试”。在你实现了一段代码之后，你将继续执行下一段代码，并且意味着“当你有时间”（你永远没有时间）回来编写测试。

还有你提到的问题。如果您在编写代码后进行了所有测试，并且您的测试发现了一些根本错误，那么您必须返回并修复所有代码以及所有测试。

实施时测试： 是

一旦你掌握了它的节奏，这种方法实际上真的很有帮助。你写了一个类，然后写了一个单元测试，不断地修改你的测试和你的代码，直到你完成。我相信它实际上比编写没有测试的代码要快。

在处理大型项目时，它也特别有用。运行单元测试以查看一个小模块是否正在工作是即时的。构建和加载整个应用程序以查看一个小模块是否正在工作可能需要几分钟时间。它也可能会打断你的注意力（这至少需要 10 分钟）。

测试内容： 尽可能多

100% 的测试覆盖率可能永远都不现实。但是绝对要测试程序的关键部分，执行数学计算或大量业务逻辑的东西。尽可能测试所有剩余的东西。没有理由测试“toString()”函数，除非这恰好对业务逻辑或其他东西至关重要。

另外，让你的测试尽可能简单，只有输入和输出。我的大部分测试函数都是两三行。如果您的函数由于组合太多而难以测试，则表明您的函数可能需要稍微分解一下。确保测试边缘情况和“不可能”的场景。

score 2 · Accepted Answer

我的经验：

如果代码不是不言自明的，或者被测试的案例是一个“棘手的”极端案例，乍一看并不明显（尽管代码可能是），请记录您的测试。
不要为您的测试创建单独的文档。如果您使用 Java，请将所有内容放在注释和 Javadocs 中。换句话说，保持这些信息接近代码。这就是需要它的地方。
关于设计和实现：只是迭代。编写一些实现，然后为它编写一些测试代码，然后是更多的实现代码，等等……直到你完成了实现和测试代码。它比编写所有实现，然后测试，然后重写失败的实现代码更快。您无法预期所有测试在设计时实现，这是不可能的。因此，如果您没有全部了解，请不要担心。
如果你覆盖了超过 80% 的代码，那么你已经很好了，越多越好。有时，代码无法测试。我推荐使用测试覆盖工具，例如 Emma for Java。

或者这实际上取决于你有多少时间？

通过不进行测试而节省的时间永远不会为您在项目后期解决错误所花费的时间付出代价。一个合适的测试集总是会在路上付出很多，总是。

2 回答 2