What is the role of a Software Architect in the Test-Driven Development process?

Question

As I understand it, Test-Driven Development is about writing tests to define the program specifications (you can correct me if I'm wrong).

If there is someone responsible for writing the specifications (including a public API) for the software (let's call him the Software Architect), does that mean that the Software Architect must write all of the tests?

Or does the Software Architect write the specifications, and then hand them over to the developers to write tests against?

Or do you allow the specifications to grow organically by allowing all of the developers to write their own tests, and forget about having a Software Architect?

Answer 1

Test-Driven Development is about writing tests to define the program specifications

You don't write tests to define the specification, the test descriptions, user stories, and feature descriptions are the specification, in the 'dead trees' sense.

To review, the TDD process in a nutshell is:

• define a project in terms of features
• describe the stakeholder, behavior, and goal of each feature using user stories
• specify the expected givens, triggering events/conditions, and behaviors/outcomes associated with a user story using test descriptions [and this completes the 'specification']
• pick a set of features for each iteration; iterations should be short [i'm omitting the planning and estimation steps for brevity]
  • code a test for a feature (it will fail, but you had to make API decisions to code the test)
  • implement enough of the feature so that the test passes
  • refactor the code if necessary
  • repeat with the next test until the feature is completed
  • repeat with the next feature until the iteration is completed
• repeat with the next iteration until the project is completed

how much design, architecture, supporting documentation, et al you choose to do is not part of TDD. There are some practical 'best practices' you can read about, but keep in mind that those are the 'best' practices in someone else's workshop, not yours.

note that the point is for the customer and the developer to come up with the features and write the stories and test descriptions together, for mutual understanding

so, with that out of the way, the original question was:

what is the role of a software architect in TDD?

And the short answer is:

Same as it ever was, same as it ever was. --David Byrne

---

EDIT: The long answer is: the architect plays the usual visionary/investigator/irritant/support/backstop roles during the entire process, as necessary.

EDIT 2: sorry I missed the point of the sub-questions! Everyone is responsible for writing the specifications; all of the developers including the architect if/when appropriate plus the customer. The developers also code the tests.

Answer 2

The Software Architect isn't writing all the tests. That would be putting too much onto one person's shoulders to my mind.

The Software Architect should be able to sketch out an initial form for the API that developers then write tests for that and then build the API. However, the Software Architect may have various code standards that aren't necessarily testable,e.g. documentation or naming conventions. There is also the potential for the initial API to be missing some calls that as an implementation is done new calls are added to the API. Thus, there will be some organic growth to the API as the code base grows but the Architect's role is in providing high-level guidelines and trying to make sure they are followed.

There can certainly be cases where a team may decide to not have a Software Architect but depending on the scale of the API and company involved this may or may not be a good idea.