Facilitated by @ruby_gem and hosted by @phpcodemonkey, the first Preston CodeJo was held last night at Magma Digital’s offices on Winckley Square. Using themed ‘katas’, this is the first of an open-ended series of events designed to challenge and extend developer abilities and interaction across programming/development disciplines.
This month’s kata asked attendees to use a Test-Driven Development (TDD) approach to solving a simple problem using the Ruby language.
The problem was to solve the higher or lower playing card question from Bruce Forsyth’s 80′s classic gameshow Play Your Cards Right. No prior knowledge of TDD or Ruby was required.
I’ve tried TDD on personal projects – with PHPUnit – but have not seen the techniques used in anger on group programming sessions before. It was fascinating to see how tempting it was to think ahead, and attempt to code ahead, and to want to skip one test in order to get ahead; at the same time seeing the benefits of having tests and production code that worked perfectly at each stage of development towards a final app.
As a further challenge, I knew nothing of Ruby – it was reassuring then that while the solution was completed, no code was used that I had not been able to familiarise myself with in the few days of reading beforehand. Working on a rapid-turnaround team project with an unfamiliar language is very rewarding.
As a next step I’d like to see how these principles are applied in production – certain parts of the problem could have been simplified early by abstracting picture cards to a single array assigning each a numeric value, testing it, and using that throughout the testing/production routines.
However the spirit (or purpose) of the event was to demonstrate ground-up TDD, testing cases one-by-one using assertions. For example, a test to assert the 5 of Hearts is a ‘higher’ card than the 3 of hearts:def test_second_card_greater_than_first_card
assert_equal(Brucie.highest_card(“3H”, “5H”), “5H”)
With each additional test and the new production code to ensure it is passed, a library of tests is accumulated, like active documentation.
I imagine most TDD developers use something ‘in-between’ the approach we tried and might add a few small ‘scene setting’ variables or constants early on.
The CodeJo ran for two hours, with a programmer at the keyboard, a ‘navigator’ beside. After 5 minutes the navigator shifts to the keyboard and another attendee takes their place, however test cases and refinements, language specifics and refactoring suggestions came as much from the audience as from those in the hot seats.
Towards the end, additional requirements were dropped in (Aces switched from high to low) so tests and production code had to be adapted, and tested in turn as before.
Before the night drew to a close (and to the pub for the retrospective) the test framework was switched to RSpec, demonstrating both a new syntax and an alternate approach to test assertions.
Code was periodically committed to Github, and may be found at ruby_gem’s github for the CodeJo.
Future events are, in the short term likely to follow the same themes, but the plan is open for discussion by attendees at the retrospectives that follow the event.
There’s alot that events like these have to offer programmers at all levels, whether that’s introducing a novice to a new language or methodology, or demonstrating to the seasoned professional how others see and work out solutions, and what they can bring to that process.
I don’t plan on missing the next one.
update: a complete solution from Tom Bell: