written this on (or about) Sat, 12 Jul 2003 20:50:08 GMT, :
>I'm committed to trying to move from Access programming to OOP/TDD, and I'm
>looking at moving to C# and/or Java. So, I'm trying to think of projects to try
>to implement as self-teaching projects.
>I've read enough now here and elsewhere to know that for TDD, the idea is
>usually to try to keep the UI as thin as reasonably possible since that's the
>hardest thing to write tests for, and code as much as possible to be UI
>agnostic. That sounds great, but my brain is having trouble bending that way.
>It's not that Access is the only thing I've ever known. I started out
>programming in Applesoft Basic, taught myself Assembly Language, then went on to
>C, Modula II, ad did a fair amount of hobbying in C++ before ending up working
>in database development using Paradox, Foxpro, then MS Access.
>Still, I find I've been steeped in Access for so long that my thought process is
>that everything starts out as a UI tied to a back-end, then sprinkle code as
>necessary (I'm a hammer now, and every problem looks like a nail to me). How to
>I develop a replacement way of thinking to break out of this? What does a thin
>UI feel like? How does code that now seems like an extension of the UI begin to
>feel like a part of the internal process instead?
Here's an exercise that will take you a few hours, and will teach you
what you want to learn. Write the game "Hunt the Wumpus". This is a
very simple game from the 70s that people used to write in Basic on
their Apple II or TRS-80, or Commodore 64.
Play it here: http://www.taylor.org/~patrick/wumpus/
As I said, write this game. HOWEVER, write absolutely no user
interface code! Write test cases that check to see that every
function works. Also write test cases to make sure that the program
knows what messages to emit and the right times. However, do not
include the strings of the messages, and do not emit the messages on
any device. Instead, write an interface (in Java) that has methods
for emitting the appropriate messages, but have the tests implement
the methods simply to verify that they were called at the right time.
Do not write code that reads commands from the user. However, *do*
write tests that invoke the functions that such commands would invoke.
I've done this exercise a few times, and it's always *very* revealing.
You can write the entire game without any UI. You can get the whole
game working without every playing it. And then, finally, as the very
last step, you can write the UI itself. You'll find that writing the
UI is trivial once you've gotten the whole rest of the program
working. You'll realize that you have thought through lots of issues
that make the UI simple to create. And yet the UI will be completely
decoupled from the game. The game won't care about the UI at all.
Robert C. Martin | "Uncle Bob"
PO Box 5757 | Tel: (800) 338-6716
565 Lakeview Pkwy | Fax: (847) 573-1658 | www.objectmentor.com
Suite 135 | | www.XProgramming.com
Vernon Hills, IL, | Training and Mentoring | www.junit.org
60061 | OO, XP, Java, C++, Python |