Question

在TDD中，每个机构都在谈论单元测试的创建以及如何进行开发。我知道整个周期，但没有机构谈论从需求中创建这些单元测试？我在文献中的某处读到，在开发这些单元测试之前创建测试列表总是好的。我的问题是： 在TDD中编写单元测试之前，究竟遵循了哪些程序（步骤）？是指在开发单元测试之前是否直接从需求中编写而不使用任何正式标准或测试列表？

Answer 1

测试列表只是下一个测试用例的临时存储库。这完全是非正式的。

测试列表的主要作用是释放你的思绪。当您考虑新的测试时，只需将其写在列表的末尾，然后您就可以忘记它，并专注于手头的问题。

没有编写测试和列表的过程，就像从需求中创建UML模型一样。您考虑问题并制作设计。设计完成后，即可开始实施。使用TDD，您可以从测试角度考虑问题，在列表中写下一些测试，然后从列表中的简单测试开始。您可以随时向列表添加（或删除）测试。

bowling game episode是一个简短的阅读，说明了从需求到单元测试的过渡。它没有提到任何测试列表。

我在单元测试源文件的底部维护我的测试列表作为注释。

void test_foobarShallFailWithNull(void) {
...
}
// the tests I *may* write next
//void test_foobarShallFailWhenX(void)
//void test_foobarShallWorkWhenY(void)

Answer 2

根据我的经验，在进行TDD时，需求用于直接识别所需的单元测试。理论上，开发人员将选择整个需求集的一个小方面，并为该方面编写单个单元测试，然后编写最简单的代码以使单个测试通过。实际上，所选择的要求和要求可能会导致开发人员同时识别多个单元测试。测试列表用作停车场，因此开发人员无需担心丢失测试想法，同时仍然可以同时关注一个测试。

Answer 3

在开始执行任务之前，您只需坐下来记下您在一张纸（或电子表格或文本文件）中可以想到的所有测试。

然后你逐一完成选择它们的清单，当它们完成时将它们分开。如果您在实施期间提出了一些新测试，则将其添加到测试列表中并继续关注当前测试。当您的列表中没有更多测试时，您就完成了。

TDD的单元测试是细粒度的，在大多数情况下，要求/规格不是。因此，您可以使用需求文档来进行系统级验收测试。要进行特定的验收测试，您可以使用TDD实现一系列任务。

Answer 4

我使用equivalence partitioning生成测试用例列表。

测试驱动开发中的测试列表的概念

4 个答案: