About
Exploring Solution Spaces, Keith Ray's blog on Software development and other topics.
Send comments to:
keithray@mac.com
| For Agile Training, eLearning, or Coaching contact: |
| Industrial Logic, Inc. |
| 866-540-8336 (toll free) |
| 510-540-8336 (Berkeley, California) |
| Links |
| xpminifaq |
| Résumé |
| “Adopting XP” Article 2002 (pdf) |
| “ Refactoring” Article 2006 |
| AYE Conference |
| Lucien W. Dupont |
| Elisabeth Hendrickson |
| Johanna Rothman's Managing Product Development |
| Brian Marick's Exploration Through Example |
| Esther Derby's Insights You Can Use |
| Laurent Bossavit's Incipient(thoughts) |
| Dale Emery's Conversations with Dale |
| Martin Fowler's Bliki |
| Creating Passionate Users |
Archives
Subscribe
RSS Exploring Solution Spaces XML
2007.Mar.27 Tue
Sometimes people new to Test Driven Development (Behavior Driven Design) focus on testing accessors, or testing constructors, or other details a little too much. In TDD/BDD, we're not testing, we're designing. When writing a executable example (aka "spec" or "test"), we're asking the questions:
1. What do we want X to do?
2. How do we want to tell X to do it?
3. How will we know when X has done it?
In answering these questions, we use (possibly not-implemented-yet) constructors, methods, accessors, etc. We then compile and run the example to see it fail; and then write code to make the example pass. And sometimes while all examples are passing, we refactor to improve the design.
When writing code to make the spec pass, we ask and answer the question:
4. How does X do it?
And when refactoring we ask and answer the question:
5. Is this the best design at this time?
To focus on "testing accessors" and "testing constructors" is to get a little too focused on the mechanics of "how does X do it?", which isn't even in the top 3 questions.