TDD on Three Index Cards 5
I had the opportunity to talk to a fellow who missed part of a class on TDD. I told him that I could give him a 15-minute overview, and give him all the essentials of TDD on three index cards.
Yes, I know that volumes have been written about TDD and BDD, and that it’s a large topic with many many branches of application, but I didn’t have time for that. I had time for three index cards. I figure that an index card is a token, and it represents a conversation, and that one can always dig deeper later.
They looked more or less like this:
Card 1: Uncle Bob’s Three Laws (Object Mentor)
- Write no production code except to pass a failing test.
- Write only enough of a test to demonstrate a failure.
- Write only enough production code to pass the test.
Card 2: FIRST Principles (Brett and Tim at Object Mentor)
- Fast: Mind-numbingly fast, as in hundreds or thousands per second.
- Isolated: The test isolates a fault clearly.
- Repeatable: I can run it repeatedly and it will pass or fail the same way each time.
- Self-verifying: The test is unambiguously pass-fail.
- Timely: Produced in lockstep with tiny code changes.
Card 3: Flow (using the famous three-node circle diagram) – origin unknown.
- Red: test fails
- Green: test passes
- Refactor: clean code and tests
Sure there is plenty more, but I didn’t know how I could provide significantly less. As is, I’m pretty happy with the exercise. Now I am wondering if I couldn’t produce most of the important information I wish to convey as a series of index cards. Would that be cool or what?
For more index card goodness, check out Indexed.
How well you summarize your thoughts! I picked up from those few words on your index cards!
“Now I am wondering if I couldn’t produce most of the important information I wish to convey as a series of index cards”
Doesn’t this defeat the purpose? Index cards are meant to be the smallest possible representation – a way to remind yourself of the deep knowledge and understanding present in the simple statements.
If you continue adding to the index cards – adding more index cards – you’re not providing any benefit, you’re just making it difficult to find the information by having a huge stack of cards that you need to sift through.
You could probably add 2 or 3 more cards to this list, at the most, before it reaches the point of diminishing returns. Keep the list small – keep the goals high level. If someone needs to know how to achieve the goal of card x, don’t give them more cards, sit down with them and teach them the details by coding with them.
...
that’s my devil’s advocate hat, for the morning. :)
Well, Derick, taken that way it would definitely be wrong.
But I teach more than one topic, so I need a few three-card decks - one for each topic.
Hi Tim,
I liked them and I have one addition from “Pragmatic Programmers” that supports yours.
Good tests are A TRIP:
Automatic Thorough Repeatable Independent Professional
Thanks a lot.