问TDD是否是一项测试任务？

EN

定义“正常”

更严重的是，在编写代码之前编写(失败)测试是TDD和BDD的本质。它意味着设计测试，然后是可测试代码。首先编写(失败)测试的结果是，它实际上改变了编写应用程序代码的方式，即可测试性。这将导致完全不同的代码。小方法只是这种方法结果的一个例子。尽管TDD意味着首先进行测试，但它通常意味着编写测试和代码，并在发现负面和边缘情况时在两者之间进行大量讨论。有两个不同的人(不是现场配对)在这将是非常缓慢的。

当另一个人(如自动化工程师)编写测试时，这通常是在给定的BDD形式下进行的。

在编写单元测试时，当您是不同角色的不同人员时，事先编写正确的测试是不实际的，因为在编写应用程序代码时，您会发现方法和负/边缘测试用例，并在编写解决方案时执行重构。以这种方式将测试和应用程序代码分离，将减缓过程，并导致质量较低的解决方案。

回到“正常”这个词。

这可能是不常见的，但使用正确的方法，如高级别的BDD，这是正确的方式。如果对你有用的话。但是，您将需要与开发人员进行大量的交互。你不一定要实施黄瓜。您可以指定给定、何时，然后在票据中供开发人员使用。我已经有效地做到了这一点，并发现它为他们提供了他们需要的规范。

外卖：

问：

• 我们希望自动化工程师指定行为(声明性)或实现细节(命令式).，例如，“用户完成添加项表单”是声明性行为，当“用户单击完整项按钮和数据库并将其带到详细信息页”是命令式行为，即“什么”(命令)与“如何”(声明性)。

那就没说重点了。

TDD是关于快速反馈的，所以开发人员编写一个检查，运行它，它失败，编写进行检查所需的最低限度的代码，再次运行检查，这一次它通过，继续写另一个检查，.

我想，除非你在一台电脑上工作并共享键盘，否则两个人不可能同步。

当然，你可以在一段时间内把它当作一个实验，然后评估它是如何为你工作的。我猜这不会有多大效果，您甚至可能在开发人员完成他的代码之后完成测试代码。很明显这根本不是TDD。

就像其他人说的那样，这将是没有意义的。

正如肯特贝克在TDD按例中所说，TDD是关于代码设计的。通过逐步定义应用程序的使用情况，测试将驱动应用程序的体系结构.

最后，建议的情况将把您转变为一个低级别的软件架构师--可能效率不高，因为您将成为团队中每一个编码工作的瓶颈。

您可能需要考虑的两个备选方案是：

• 行为驱动开发：您可能希望与团队的其他成员合作，定义描述软件工作的场景，并创建模拟用户与软件交互的自动化，使用这些模拟来驱动应用程序本身的开发。下面是应用程序API的设计，而不是它的体系结构。
• 对编程：对于架构工作，您可以与开发人员并肩工作，与他们一起编写将驱动软件设计的测试，这样您就不是瓶颈，而是一个助手。您可以看到对编程这里的一些好处。