So, the RSpec book is almost out of beta. I’ve been through parts of it off and on over the last couple years, and I can highly recommend it. Through the book, as an example of building a real application with the BDD workflow, a codebreaker game is created. The rules are simple: the computer chooses a 4-digit sequence of colors, then the player guesses the sequence. After each guess, a result is displayed that indicates 1) how many colors are correct and in the right place, and 2) how many colors are correct, but in the wrong place.
For this kata, I build the marking algorithm. So, giving a secret code and a guess, the kata is to generate a the result. For example
Secret: r y g b
Guess: b g c c
Mark: ['m', 'm'] – two colors right, but in the wrong place
Secret: r y g b
Guess: r b c y
Mark: ['p', 'm', 'm'] – one color in right place (r), and two colors right, but wrong place (b, y)
I will be finishing up the git repo tonight, although it already has the cucumber feature and 2 reference implements. I will be adding the standard spec list branch and implemented specs branch, as well.
And, thanks to Techsmith for donating licenses to Camtasia for doing the screencasts. I have found it pretty easy to record/edit and publish these due to Camtasia.
Enjoy! As always, I appreciate any and all feedback in the comments section. Or, better yet, write a post on your blog with a screencast of your own!
(it is tough to see so small, just click the full-screen button on the video. Or, you can go to vimeo and download the source video directly).
Codebreaker – Marker from Corey Haines on Vimeo.
[...] few minutes ago, I was watching a great screencast of Corey Haines doing a kata. I stopped when he was refactoring a few similar assigments. There was something I’ve never [...]
Really enjoyed watching the progression of this one. The steps were obvious even with the magic bitwise methods etc. That let() method looks interesting, I’ll have to play with that!
How did you arrive at the finished Cucumber feature suite? Was that built up iteratively as you refined the kata? Seeing this exercise done along with the cucumber testing process would have been interesting too, but maybe a bit too long? Maybe save that for another shorter kata?
Cheers. Thanks for putting these out, they’re very enlightening.
Hi, Andrew,
Thanks for watching. I had a good time doing this one; I think there are some fun parts of it. Jeremy Lecour (in the comment above yours) wrote a nice blog post about let(), so I’d recommend starting there. Personally, other than the custom matchers, it could be my favorite part of rspec.
The cucumber feature and scenarios were built beforehand based on the rules of the game. I wrote them to capture what I expect the marks to be. I then was able to use them to guide my progress.
Yeah, seeing the cucumber scenarios built would be an interesting kata. Unfortunately, for something like this, it would add a lot of overhead time – I am already pushing the limit of how long I would like my katacasts to be.
I’m hoping to do a short one next time (after Enrique does his next week), perhaps I can find a nice exercise that I can do in 5 minutes, or so.
Hi, Corey,
I have a few questions for you, if you don’t mind.
1. About how many times did you exercise this before doing the actual screencast?
2. I haven’t read the RSpec book, as Ruby is not my main language, so I may miss something obvious, but… why did you define the Marker’s interface beforehand? Wouldn’t it better reflect the usefulness of TDD as a design tool if one would postpone the naming of the methods?
That would be all, at least for the moment. Thanks for posting these.
Ionut,
1, I did the exercise between 5-10 times, I think. I ended up changing the way I did it around the 7th time, so I didn’t have time to practice it totally, which is why there are a few moments in there of indecision.
2, You are absolutely correct regarding the pre-definition of the interface for Marker. That is an important point to make regarding using TDD as a means for designing your interface. I actually had it defined as part of the cucumber scenarios, so that they would not be failing for ‘missing method’ problems.
Since these katas tend to be small, focused practices of different things, they won’t always be a great example of completely end-to-end, real-world test-driven development.
Thanks for raising this point, though, so people don’t confuse what goes on in this kata with a true, ‘this is how you should do tdd’ lesson. thanks.
I really enjoyed this one. It flowed nicely and looked very well practiced, Corey.
I always enjoy the early test refactorings and this was a really nice example. The custom matcher and the let() made things look much less cluttered. Very nice. I wasn’t really aware of the let() method before now. I really need to get the RSpec Book to the top of my reading list (assume it’s described in there).
What Vim plugin(s) are you using for the method/variable autocompletion and popups? Is your .vimrc anywhere public?
Keep up the good work!
Hi Corey,
My name is Gil, I’m from Typemock. We do a weekly video cast called “This week in testing”. This week we talked also about Kata casts. It’s here: http://learn.typemock.com/this-week-in-test/2009/11/11/episode-3-magic-numbers.html
Come and watch, and if you think it’s worth it (and you will), send some viewers our way too.
Thanks,
Gil Zilberfeld
Typemock
Hi Corey, excellent screencast! Nice to see how you are really attached to baby steps within the red/green/refactor cycle.
Make Andrew’s also my words: this is really very enlightening.
@james I’m pretty sure it is the Vim’s autocomplete CTRL+P
I just heard about katacasts yesterday listening to a backlog of .NET Rocks episodes. I started watching them to help remind myself of how ideally I should be doing TDD. A nice side-effect has been learning a bunch of Ruby. (Professionally, I’ve been a .NET and Java person.) So far, unfortunately, I’ve had to pause a lot to go look up expressions and methods in online Ruby docs. I’m learning a lot! Keep up the good work!