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

Question

在 SDLC 中，测试过程应该在实现之后立即进行。然而，测试驱动开发鼓励我们在做实现的同时做测试。在我的讲座类(class)中，教授说测试用例应该是设计的一部分。

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

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

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

非常感谢。

Answer 1

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

实现后测试: 否

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

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

在实现时进行测试: 是

一旦掌握了节奏，这种方法实际上非常有用。您编写了一些类，然后编写了一些单元测试，并不断修改您的测试和代码，直到完成。我相信它实际上比不进行测试就编写代码要快。

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

要测试的内容: 尽可能多

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

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