问软件架构师在测试驱动的开发过程中扮演什么角色？

EN

测试驱动开发是关于编写测试来定义程序规范的。

您不会编写测试来定义规范，在“死树”的意义上，测试描述、用户故事和特性描述都是规范。

简单地说，TDD过程是：

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

• 重复下一次迭代，直到项目完成。

您选择做的设计、体系结构、支持文档等并不是TDD的一部分。有一些实用的“最佳实践”，你可以读到，但请记住，这些是‘最佳’实践在别人的研讨会，而不是你的。

请注意，关键是客户和开发人员要想出这些特性，并一起编写故事和测试描述，以便相互理解。

所以，在这种情况下，最初的问题是：

软件架构师在TDD中的角色是什么？

简单的回答是：

和以前一样，和以前一样。-大卫·伯恩

编辑:很长的答案是:架构师在整个过程中(视需要)扮演通常的visionary/investigator/irritant/support/backstop角色。

编辑2:对不起，我漏掉了分题的要点！每个人都负责编写规范；所有的开发人员，包括架构师，如果/在适当的时候加上客户。开发人员还编写了测试代码。

软件架构师并没有编写所有的测试。这会让我觉得一个人的负担太大了。

软件架构师应该能够为API勾勒出一个初始表单，然后由开发人员为它编写测试，然后构建API。但是，软件架构师可能有各种不一定是可测试的代码标准，例如文档或命名约定。初始API也有可能丢失一些调用，当实现完成时，会向API中添加新的调用。因此，随着代码库的增长，API将有一些有机的增长，但架构师的角色是提供高级别的指导方针，并努力确保它们被遵循。

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