Applying Test-Driven Development to Architecture to Keep Your Team on Target
- Discovering Value
- Communicating Value to the Team
- Vision Tests
- Link Tests
- Conclusion
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Software architects are often talented problem solvers. How can your Agile team leverage its architects' capabilities, while still delivering value responsibly? Test-driven architecture makes the role of architect relevant in the Agile age.
We've all seen the decentralization of technical decision-making in Agile environments. Authority has moved away from individuals and toward teams, who are expected to make great decisions simply because they have to live with the consequences. The architect role can still have a place there, because someone needs to keep an eye on the "bigger picture," coordinating integration and generally moving the team in the right direction.
Test-driven architecture gives architects a language they can use to express value to your team. The team can then take as a goal the value proposed by the architect, applying each individual's ingenuity, intelligence, and the collaboration of the team as a whole to bring that vision of value to reality.
What exactly do we mean by "value"? We use the word value a lot in this article, and that word can have many meanings. In this context, we mean "value as the user or customer would see it" (see Figure 1).
)
Figure 1 Examples of value and non-value.
Software development teams benefit from the existence of tests that express value. Stakeholders enjoy this transparent representation of the value being produced. Managers, quality assurance, other architects, other teams, product owners, and other people can all speak and read the language you're using to express and verify value. This approach promotes collaboration—and, in our opinion, vastly increases the chance of success.
Discovering Value
The software industry is just barely getting to the point of building things that can be changed while remaining consistently functional. Software teams chronically deliver features that aren't suited to the task they're meant to achieve—or they don't work well with other features.
In the modern world, we believe that ensuring a smooth flow of value through a series of related features is a major part of an architect's job. The industry's consistent failure to accomplish this goal is a pretty big problem from an architect's perspective.
We've found that applying test-driven development (TDD) at the architectural level does a lot to help an organization build the "right" thing. This is true for the same reason that TDD gives developers a similar benefit at the class-design level: Having a concrete artifact focuses your attention and creates a natural, tight feedback loop through which an architect's understanding of a value stream can be refined repeatedly in the space of just a few hours. The architect also generates something useful (a test) instead of something worthless (documentation) in the process.
Let's consider a simple example. Imagine that you're extending a system for a company that makes custom-printed office supplies. Following is one requirement for a new initiative (see Figure 2):
I want to carry the design details all the way through to the end of the manufacturing phase of a pen, so that it can be used to validate each step of the process before we move on to the next.
)
Figure 2 Pen manufacturing value stream.
This is one of those classically simple statements that could potentially hide deep and far-reaching complexity. It defines one end of the value stream—but where's the other? Once you know what steps you're supposed to care about, what kind of design information needs to be transmitted? After that detail has been established, you also need to figure out how validation should be triggered and how its results must be captured. How much functionality is too much?
Writing down the steps in a test that's detailed enough for a computer to execute forces you to identify and answer most or all of the potential questions early in the development process. In the next section, we explain how that information can be used to drive development.