在测试驱动的开发过程中，软件架构师的作用是什么？

据我了解，Test-Driven Development是关于编写测试以定义程序规范的（如果我错了，可以纠正我）。

如果有人负责编写软件的规范（包括公共API）（我们称他为Software Architect），这是否意味着Software Architect必须编写所有测试？

还是由软件架构师编写规范，然后将其交给开发人员编写测试依据？

还是通过允许所有开发人员编写自己的测试而使规范有机地增长，而忘记了拥有软件架构师？

测试驱动开发涉及编写测试以定义程序规范

您无需编写测试来定义规范，从“死树”的意义上讲，测试描述，用户案例和功能描述就是规范。

回顾一下，TDD流程概括如下：

• 根据功能定义项目
• 使用用户故事描述每个功能的涉众，行为和目标
• 使用测试描述来指定与用户故事相关的预期给定，触发事件/条件以及行为/结果[并完成“规范”]
• 为每次迭代选择一组功能；迭代应该简短[为简洁起见，我省略了计划和估算步骤]
  • 为功能编写测试代码（该测试将失败，但是您必须做出API决定才能对该测试进行编码）
  • 实现足够的功能，以便测试通过
  • 必要时重构代码
  • 重复下一次测试，直到功能完成
  • 重复下一个功能，直到迭代完成
• 重复下一次迭代，直到项目完成

您选择要做多少设计，架构，支持文档等不属于TDD。您可以阅读一些实用的“最佳实践”，但是请记住，这些是别人的工作室而不是您的工作室中的“最佳”实践。

注意的一点是客户和开发商拿出的特点和故事和测试说明写在一起，相互理解

因此，顺便说一句，最初的问题是：

TDD中软件架构师的作用是什么？

简短的答案是：

曾经一样，曾经一样。-戴维·伯恩

编辑2：对不起，我错过了子问题的重点！每个人都有责任编写规范；所有的开发人员，包括建筑师（如果有的话）以及客户。开发人员还对测试进行编码。

软件架构师并未编写所有测试。在我的脑海中，这太过分了。

软件构架师应该能够为API勾画出一种初始形式，开发人员可以为该形式编写测试，然后构建该API。但是，软件设计师可能具有不一定可测试的各种代码标准，例如文档或命名约定。最初的API可能还会丢失一些调用，这些调用在实施完成后会向API添加新的调用。因此，随着代码库的增长，API会有一些有机的增长，但是架构师的作用是提供高级指导并努力确保遵循。

当然，在某些情况下，团队可能会决定不聘用软件架构师，但根据所涉及的API和公司的规模，这可能不是一个好主意。