テスト駆動開発プロセスにおけるソフトウェアアーキテクトの役割は何ですか？

私が理解しているように、テスト駆動開発はプログラムの仕様を定義するためのテストを書くことです（私が間違っていれば修正できます）。

ソフトウェアの仕様（パブリックAPIを含む）を作成する責任者がいる場合（彼をソフトウェアアーキテクトと呼びましょう）、それはソフトウェアアーキテクトがすべてのテストを作成する必要があることを意味しますか？

または、ソフトウェアアーキテクトが仕様を作成してから、それらを開発者に渡してテストを作成しますか？

それとも、すべての開発者が独自のテストを作成できるようにし、ソフトウェアアーキテクトの存在を忘れることによって、仕様が有機的に成長することを許可しますか？

テスト駆動開発は、プログラム仕様を定義するためのテストを記述することです

仕様を定義するためのテストを記述しないでください。テストの説明、ユーザーストーリー、機能の説明は、「枯れ木」の意味での仕様です。

復習すると、TDDプロセスの概要は次のとおりです。

• 機能の観点からプロジェクトを定義する
• ユーザーストーリーを使用して、各機能の利害関係者、行動、目標を説明する
• テストの説明を使用して、ユーザーストーリーに関連付けられた予想される条件、トリガーイベント/条件、および動作/結果を指定します[これで「仕様」が完成します]
• 反復ごとに一連の機能を選択します。反復は短くする必要があります[簡潔にするため、計画と推定のステップは省略しています]
  • 機能のテストをコーディングします（失敗しますが、テストをコーディングするためにAPIを決定する必要がありました）。
  • テストに合格するために十分な機能を実装する
  • 必要に応じてコードをリファクタリングする
  • 機能が完了するまで次のテストを繰り返します
  • 反復が完了するまで次の機能で繰り返します
• プロジェクトが完了するまで次の反復で繰り返す

設計、アーキテクチャ、サポートドキュメントなど、どれを選択するかはTDDの一部ではありません。あなたが読むことができるいくつかの実用的な「ベストプラクティス」がありますが、それらはあなたのものではなく、他の誰かのワークショップでの「ベスト」プラクティスであることを覚えておいてください。

重要なのは、相互理解のために、顧客と開発者が機能を考え出し、ストーリーとテストの説明を一緒に書くことです。

だから、それが邪魔にならないで、元の質問は：

TDDにおけるソフトウェアアーキテクトの役割は何ですか？

そして短い答えは：

今までと同じ、今までと同じ。-デビッド・バーン

編集2：申し訳ありませんが、サブ質問のポイントを逃しました！誰もが仕様を書く責任があります。必要に応じてアーキテクトを含むすべての開発者と顧客。開発者はテストもコーディングします。

ソフトウェアアーキテクトはすべてのテストを作成しているわけではありません。それは一人の肩に負担をかけすぎてしまいます。

ソフトウェアアーキテクトは、開発者がAPIのテストを記述してAPIを構築するためのAPIの初期フォームをスケッチできる必要があります。ただし、ソフトウェアアーキテクトには、必ずしもテスト可能ではないさまざまなコード標準（ドキュメントや命名規則など）がある場合があります。また、初期APIの一部の呼び出しが欠落する可能性もあります。実装が完了すると、新しい呼び出しがAPIに追加されます。したがって、コードベースが成長するにつれて、APIにいくらか有機的な成長が見込まれますが、アーキテクトの役割は、高レベルのガイドラインを提供し、それらが遵守されていることを確認することです。

確かに、チームがソフトウェアアーキテクトを持たないことを決定する場合もありますが、APIの規模と関与する会社によっては、これは良いアイデアかもしれませんし、そうでないかもしれません。