http://eli.thegreenplace.net/2011/10/04/what-tdd-means-to-me/
What I do before writing code is thinking about the testability of my design. Thinking hard.
Design usually means breaking the solution into components (or modules, or whatever you want to call them), figuring out the responsibility of each component and the interactions between them. There are many aspects to consider when judging a certain design, and I add testability as an important first-class criterion. A design that doesn’t lend itself to being tested, is in my view a bad design, so I start thinking about alternatives.
How does a design lend itself to being tested? By being composed of components that can be tested in isolation.
Isolation is extremely important for debugging problems when they unavoidably arise. It is not easy to achieve – good isolation (a.k.a. encapsulation) of components is a kind of holy grail – you never really find the best division into components, you only approximate it.
I think that testability serves as a good guide – components that are easy to test in separation usually make up a pretty good design. This is because testability and isolation usually go hand in hand. The more coupled a design is, the harder it makes testing its components in isolation. As a corollary – when components are easy to test in isolation, the design is well decoupled.
No comments:
Post a Comment