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?

  • There is some debate over on english.se on what you mean by "grow organically" - english.stackexchange.com/questions/17853/… - would you like to confirm :)
    – JoseK
    Mar 25 '11 at 11:28
  • @Jose: The last sentence in my OP is meant to be slightly tongue-in-cheek, as it seems obvious to me that a program must always have detailed specifications from a customer. But customers don't always know what they want exactly, which is why iterative software development processes exist. See here for more information about the "growing software" metaphor. Mar 25 '11 at 14:58
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.

  • 1
    That makes sense, but the only steps I have ever heard people talk about within the context of TDD are the five steps in your five inside bullets (describing the red-green-refactor process). Are the remaining bullets really part of TDD proper, or are they a part of some larger encompassing methodology like Agile or DDD? Nov 25 '10 at 3:59
  • @Robert hmmm...good question! technically the other bullets would be XP; I learned XP and TDD at the same time and never thought to separate them. Until now ;-) Nov 25 '10 at 4:38
  • @Robert did some refresher reading; see edits (FYI using XP ref extremeprogramming.org and TDD ref agiledata.org/essays/tdd.html#WhatIsTDD) Nov 25 '10 at 4:44
  • Hmm, the link you provided for TDD says that TDD is really Test-Driven Design. Now I'm back where I started. "You design organically, with the running code providing feedback between decisions." Nov 25 '10 at 5:04
  • 1
    @Robert the edits certainly helped me to understand the question better. I take the D as Development and interpret it as the entire lifecycle, not just the coding part. TDDev is a good way to learn architectural skills - the refactoring has a tendency to push one in that direction Nov 25 '10 at 5:25

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.