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
2005.Oct.24 Mon
The most common attitude about test-driven development and user-interface code is that the two don't combine well. I have only attempted a small amount of test-driven UI code - on MacOS Carbon and Java Swing - and didn't find it terribly helpful. I may try again with Cocoa and see how that works out.
The danger of having GUI code as a coding-area designated "not to be test-driven" is the temptation to write the GUI code first, and to mix in business logic code with the GUI code. Avoid that temptation.
Your business logic could have multiple user-interfaces: a Mac UI, a Windows UI, a Unix/Linux UI, a command-line interface, a scripting UI via COM on Windows or AppleScript on MacOS X, or an embedded scripting language, and even a web-interface. Using FIT/Fitnesse means that you also have an acceptance-testing interface.
Keep the UI from mixing with the business logic by test-driving the business logic first. This makes writing portable, multi-platform code much easier since UI code is very often single-platform. Even if you don't plan on writing portable code, TDD-ing the business logic before coding the UI still provides a separation of concerns that is a hallmark of good design, and allows better re-use of the business logic within the same project or different projects.
Therefore, to avoid mixing business business logic with the GUI code and thus creating code that's unnecessarily coupled and non-cohesive, test-drive the business logic code first, and write the GUI code last. Sometimes a spike might be necessary to find out what the GUI framework requires. Don't forget to throw away the spike code after you discover what you need to learn.