使用TDD进行规划单元测试

Question

当你接近想写的课时，你如何计划单元测试？ 您是否使用正式模板或使用笔和纸/记事本？ 我正在寻找一些方法让其他程序员/ QA知道应该实现哪些测试（如果忽略某些东西，可以更容易发现它）。

Answer 1

Answer 2

我不认为使用TDD可以很好地使用模板。我假设您已经通过示例阅读了Kent Beck关于测试驱动开发的书。如果没有，请这样做。

但总体思路很简单。当我们开始上课时，我们将对课程的责任有一个大概的了解。这是我们使用的步骤：

1. 对课程有一个总体思路 责任和使用 用于命名班级的信息。

2. 为此课程创建一个测试用例。

3. 如果您从有关类内部单元的具体信息开始，只需在类中编写这些存根，并为这些存根编写测试用例。最初所有这些都会失败，大多数方法的签名都会改变。这就是整个想法。

4. 在大多数情况下，开发者可能没有那种程度的信息。在这种情况下，可以在First Test中开始编写代码。测试通过后，将逻辑迁移到类中。

所以我正在推动的是，TDD的重点在于使开发过程更加有机。课程增长，知道应该做什么。拥有正式模板或写下来可能没有用。

我唯一能想到的就是在每次迭代之前与开发人员坐在一起，并对每个组件类及其职责提出一个非常详细的想法（我们只使用此讨论来完成公共API ）。

如果您想了解开发人员编写的测试用例的质量，那么您可以进行临时代码审查，以查看这些类是否正确分解为单元并且所有单元都经过测试。

Answer 3

TDD不是您要寻找的方法; - ）

way to let other programmers/QAs know what tests should be implemented

这句话暗示你是在经过测试之后，但TDD本身是由需求驱动并产生功能 - 事实上它也产生了一套测试，这是一个附带的（但非常强大的）附属物，它恰好导致了一个回归套件。

虽然TDD利用'测试'来推动代码开发，但您不需要预先指定测试。即使你这样做（有时也有助于'思考'这样做），程序员可能不需要编写所有测试以便在代码中产生所需的行为。实际上，在TDD中，当所有测试都通过时，我们鼓励你停止工作 - 你不需要继续编写测试只是为了发现它们已经通过了;这类似于制作。

此外，TDD的另一个副作用是拥有（并持续运行）回归套件。如果在以后发现错误，只需通过测试套件就可以更轻松地编写另一个测试，该测试演示了测试失败的错误。修复错误后，测试应该通过 - 所有套件中的其他测试。

Answer 4

您不能承诺使用TDD并让其他人进行单元测试。你的这个要求强烈暗示你还没有理解TDD范式。

在我的（公认的相当新的）经历中

• 您编写的测试如果通过，将确认您对目标功能的初步了解。此时不会写入任何一行生产代码。
• 然后，您实施生产代码，以便传递单元测试。
• 如果您的理解发展，那么您可以更改单元测试或/和添加新单元测试
• 然后，您可以在生产代码中实施更改，以便测试通过
• 到那时，如果您发现生产代码的某些部分未被涵盖，则不禁止编写其他单元测试。
• 删除不再有意义的测试。
• 你得到了美丽清晰的代码：o）

TDD不是QA方法;这是一种发展方式。整个想法是单元测试指导开发过程。所以你真的不能让别人为你做单元测试。

Answer 5

我首先设计类，通常使用简单的UML类图。我尽量不使图表足够详细，以便我可以对它运行测试（例如为每个方法指定的params和返回类型，我知道方法的行为如何影响对象状态）。

然后，我编写单元测试。通常，当涉及到自动化测试时，您应该为您的类中定义的每个方法使用1种测试方法。就惯例而言，如果我的班级中有一个名为myMethod的方法，那么我的单元测试方法将被称为testMyMethod。

我使用我对方法预期行为的了解来编写单元测试，然后编写方法并检查以确保它通过了单元测试。