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
2006.Jul.20 Thu
12 Benefits of Test Driven Development
J. Timothy King blogs about 12 benefits of TDD. Check it out.
When I was programming in Pascal a long time ago, we had Functions and Procedures. Functions returned a value, Procedures did not. But there was more to it than that. Procedures had side-effects, but functions generally did not. This idea is called “Command-Query Separation” and it is useful today when writing object methods. Quoting from the Wikipedia:
Command-query separation (CQS) is a principle of object-oriented computer programming. It was devised by Bertrand Meyer a part of his pioneering work on the Eiffel programming language.
It states that every method should either be a command that performs an action, or a query that returns data to the caller, but not both. More formally, methods should return a value only if they are referentially transparent and hence possess no side effects.
On Behaviour-Driven Development
Two Quotes from http://behaviour-driven.org/GettingTheWordsRight. (It's a wiki, this page seems to be authored by Dan North and Dave Farley.)
"Behaviour-Driven Development grew out of a thought experiment based on Neuro-Linguistic Programming techniques. The idea is that the words you use influence the way you think about something."
"Concentrating on finding the right words led us to think about the process differently, for example, the fact that the words we use in BDD are very much focussed on the behaviour of the system led us to better understand the very close relationship between the stories we use to specify behaviour and the specifications we implement in BDD in place of tests. It also helped us gain further insight into some of the failure modes we have experienced in TDD projects."