테스트 주도 개발 프로세스에서 소프트웨어 아키텍트의 역할은 무엇입니까?

내가 이해하는 것처럼 Test-Driven Development는 프로그램 사양을 정의하기 위해 테스트를 작성하는 것입니다 (잘못되면 정정 할 수 있습니다).

소프트웨어의 사양 (공용 API 포함)을 작성해야하는 사람이 있다면 (소프트웨어 아키텍트라고 함) 소프트웨어 아키텍트가 모든 테스트를 작성해야합니까?

또는 소프트웨어 아키텍트가 사양을 작성한 다음 개발자에게 테스트를 위해 넘겨 줍니까?

또는 모든 개발자가 자체 테스트를 작성하고 소프트웨어 아키텍트를 잊어 버려서 사양이 유기적으로 커지도록 허용합니까?

테스트 주도 개발은 프로그램 사양을 정의하기위한 테스트 작성에 관한 것입니다.

사양을 정의하기위한 테스트를 작성하지 않고 테스트 설명, 사용자 스토리 및 기능 설명 은 '데드 트리'의미에서 사양입니다.

간단히 말해서 TDD 프로세스는 다음과 같습니다.

• 기능 측면에서 프로젝트를 정의
• 사용자 스토리를 사용하여 각 기능의 이해 관계자, 행동 및 목표 설명
• 테스트 설명을 사용하여 사용자 스토리와 관련된 예상되는 주어진 이벤트, 조건, 트리거 된 동작 / 결과를 지정합니다.
• 각 반복마다 기능 세트를 선택하십시오. 반복은 짧아야한다 [간단하게하기위한 계획 및 추정 단계를 생략하고있다]
  • 기능에 대한 테스트 코딩 (실패하지만 테스트를 코딩하기 위해 API 결정을 내려야 함)
  • 테스트가 통과되도록 충분한 기능을 구현하십시오.
  • 필요한 경우 코드를 리팩터링
  • 기능이 완료 될 때까지 다음 테스트로 반복
  • 반복이 완료 될 때까지 다음 기능으로 반복
• 프로젝트가 완료 될 때까지 다음 반복으로 반복

디자인, 아키텍처, 지원 문서 등의 양이 TDD의 일부가 아닙니다. 당신이 읽을 수있는 실제적인 '모범 사례'가 있지만, 다른 사람의 워크숍 에서는 '모범'사례가 아니라는 것을 명심 하십시오.

요점은 고객 과 개발자가 상호 이해를 위해 기능을 생각해 내고 스토리와 테스트 설명을 함께 작성하는 것입니다.

그래서 그 길에서 원래의 질문은 다음과 같습니다.

TDD에서 소프트웨어 아키텍트의 역할은 무엇입니까?

그리고 짧은 대답은 다음과 같습니다.

예전과 동일합니다. -데이비드 번

편집 2 : 미안 나는 하위 질문의 요점을 놓쳤다! 모든 사람 은 사양을 작성해야합니다. 적절한 경우 고객을 더한 아키텍트를 포함한 모든 개발자 . 개발자 는 또한 테스트를 코딩합니다.

Software Architect가 모든 테스트를 작성하지는 않습니다. 한 사람의 어깨에 너무 많은 생각이 들었습니다.

Software Architect는 개발자가 API에 대한 테스트를 작성한 다음 API를 빌드하는 API의 초기 양식을 스케치 할 수 있어야합니다. 그러나 소프트웨어 아키텍트는 반드시 문서화 또는 명명 규칙과 같이 반드시 테스트 할 필요는없는 다양한 코드 표준을 가질 수 있습니다. 또한 초기 API에 구현이 완료되면 새 호출이 API에 추가되는 일부 호출이 누락 될 수 있습니다. 따라서 코드베이스가 커짐에 따라 API에 유기적 인 성장이있을 수 있지만 Architect의 역할은 높은 수준의 지침을 제공하고이를 따르도록 노력하는 것입니다.

팀이 소프트웨어 아키텍트를 갖지 않기로 결정할 수도 있지만 API의 규모와 관련 회사에 따라 좋은 아이디어 일 수도 있고 아닐 수도 있습니다.