Posted by Doug
Thu, 29 Sep 2005 18:31:00 GMT
My partner and I are trying to implement the state changes of two people initiating a meeting and negotiating the time. Thanks to TDD we worked through it!
For a while we sat there talking about “what if”, “and then”, “but what about” trying to get our minds around the whole process. We had tried coding a couple of times only to whack half-baked ideas.
Finally I came to my senses, “Even if we don’t understand the whole process, we know what this simple case should look like.” I wrote a five line functional test, and went and hard-coded the controller to make it pass. Success! We made something work!
So Dave says, “OK, if that’s the way that should work, this case should look just like this,” and codes another test. We then go and hard-code an elsif clause for that test. Four tests later and some refactoring we had our logic working the way it should.
A couple things we experienced. First, we didn’t really know what to do but was able to code an ultra simple test. That was enough to get us moving in the right direction. Second, we didn’t have to code the final, elegant solution. We just hacked together something that would work for the simple test we had. It wasn’t until we had done that a couple times that we could effectively “triangulate” what the elegant solution should be.
Posted in Programming, Test Driven Development, Ruby on Rails | no comments
Posted by Doug
Tue, 30 Aug 2005 14:31:00 GMT
My good friend, Mark Windholtz, loaned me a copy of Kent Beck’s Test Driven Development by Example
. While I’ve been practicing TDD for a while now and experimenting with various techniques, I hadn’t actually read this book yet. I found it very enlightening even though I already had some TDD experience.
I have been convinced for a long time that automated tests are the way to go. TDD seems like the logical conclusion to that belief. What the book does is explicitly define the procedure of red/green/remove duplication, why that works, and patterns that come out of it. There’s almost a third of the book related to testing patterns. Most of the book is targeted towards Java, but the patterns are pretty applicable to Ruby on Rails too. Having read this book will definitely improve my development practices.
I feel I should mention that the overall tone of this book is much more informal than the XP books I’ve ready by Kent Beck. Also, I really liked the acknowledgment he wrote about Ward Cunningham.
My life as a real programmer started with patient mentoring from and continuing collaboration with Ward Cunningham. Sometimes I see Test-Driven Development as an attempt to give any software engineer, working in any environment, the sense of comfort and intimacy we had with our Smalltalk environment and our Smalltalk programs. Tere is no way to sort out the source of ideas once two people have shared a brain. If you assume that all of the good ideas here are Ward’s, then you won’t be far wrong.
I’ve communicated with Ward several times via IM and a couple times over the phone. I like him a great deal. Kent certainly gets a lot of attention because he writes the books. He’s never shy of giving credit to Ward. Ward’s such an easy going guy. He doesn’t push himself on you; it’s more like he infects you. With all I know about Ward, one of my career goals is for someone to say I’m like him. Of course, I’m far from that now. For starters, I need another 15 to 20 years of solid experience.
Posted in Programming, Software, Test Driven Development, Books | 2 comments
