2nd London Python Dojo & TDD

The 2nd London Python Dojo took place last night, space & food again courtesy of Fry-IT. The format was pretty much the same with the difference that the task was more of a program-y one and less of an API-y one. Which had the result that the audience was far more engaged (read: lots of opinionated backseat drivers) than on the previous week. It was still fun and the proposal that we essentially carry on with the same problem domain (a noughts & crosses game) next time was fairly well received.

What interested me a little more was the differences of approach among the developers present, both those up-front and those in the cheap seats. As I touched on last week, a Test-Driven Development technique was assumed (at least by the organisers). Now, as far as I can tell, while this is a perfectly valid approach to development, it isn’t of the essence of Dojo — ie you don’t need to do TDD for a Dojo to work. The point of a Dojo is rather to code and learn in front of others. Neither does it need to involve pair programming per se.

Now my point is not that I disagree with these techniques, altho’ I’m happily not using them myself in my every day life, but rather that a certain amount of the “suggestions” from the body of the audience was centred on their use. One or two of the coders were clearly not accustomed to working that way, or even aware that you could perhaps, and my own feeling is that this should be perfectly permissible. I’m not saying that anyone was booed off stage for launching in without a test, but there were several strong voices of encouragement in the crowd pointing out that a failing test had not been written (or any test, for that matter) as though True Development were impossible without one!

FWIW, my view on Test-Driven Development is rather like my view on Object-Oriented Development: that it’s an arrow one should certainly have in one’s quiver but that it isn’t always applicable. I realise that the comparison is not the most apt, but go with it for now. I appreciate that the people who were coding were not necessarily in their element and that I may not have been seeing TDD at its best, but there were not a few moments when I felt that a test was being written simply because it should be, according to the Mantra, without any thought to the program, design, goals, structures etc. At one point it was suggested that a particular function should return a string rather than print it to the screen as it would be easier to form a test. Now my view is that if a function needs to print a string then it needs to print a string. The *test* shouldn’t be driving the needs of your program: the requirements should be doing that. (In that case, it could well have been a pragmatic choice since the alternative would presumably have been to construct a mocked sys.stdout but still…).

As I say, I’m sure I wasn’t seeing TDD at its best and brightest. I would genuinely welcome a Masterclass Dojo (or whatever they’re called) where someone walks through a test-driven development to show how it might be done. As it was, I felt that the need to invent a test for something before you did anything about it left you seeing only the trees and failing to get a grasp of the wider wood. My 2.5d-worth.

4 Comments so far »

  1. Paul Boddie said,

    Wrote on October 16, 2009 @ 4:00 pm

    “At one point it was suggested that a particular function should return a string rather than print it to the screen as it would be easier to form a test.”

    A million turtles later: “Are we ready to print to the screen now?”


  2. OpenIDTartley said,

    Wrote on October 19, 2009 @ 10:39 am

    Hey there Tim.

    Fair points all over. I do believe it was I who made the particular suggestion to return a string rather than printing it, because that would be easier to test.

    My justification would be that, in my understanding, one significant point of the dojo is to practice and demonstrate the use of development and refactoring techniques, such as TDD, without the distractions of real-world complexities.

    So we choose an extremely simple and small problem, and apply those techniques to it. In a real world scenario, we would not need to, because the problem is so simple. But here, we do anyway, because the point is not to solve the problem in exactly the same way you would solve that problem in real life. The point is to demonstrate and practice the techniques that, later, you would use in the thick of a real-world problem.

    So, I think that my suggestion of returning strings instead of printing them is an example of recognising that some code is hard to test, whereas functional code is much easier to test, and modifying your production code accordingly to make it easy to test. This is, to my mind, precisely what the dojo is for. It may not have been necessary, but it exemplified somethign that people will absolutely find useful in other, more complex, scenarios.

    Make any sense, do you think?

    Big hugs!


  3. tim said,

    Wrote on October 19, 2009 @ 12:51 pm

    @Tartley: thanks for the response, Jonathan. Your point about using the Dojo to illustrate certain techniques, eg a slight refactoring of code to facilitate a particular testing paradigm, is perfectly sound. I just think that there’s a certain fuzziness due to the fact that everyone has a slightly different intuition about what the Dojo should be about.

    Part of the issue is, obviously, that you have one pilot, one co-pilot and 20+ backseat pilots. And no-one’s giving authoritative “this the best way because…” advice; it’s just a melee of noise and advice.

  4. OpenIDTartley said,

    Wrote on October 21, 2009 @ 6:48 pm

    Very true that there is much fuzziness. Maybe this is a lesson we can learn - that people might actually get more out of we set everyone’s expectations in the same direction by trying to define more tightly what the dojo is aimed at. I wouldn’t want to narrow the scope of the dojos down to just one thing, I am thus far enjoying the organic and scattershot approach. Maybe though, there is mileage in an organiser saying “*this* dojo is to demonstrate X and Y. Future dojos may be about somethign else.”

    I’ll chat with peeps about this at the Pyssup tonight.

Comment RSS · TrackBack URI

Leave a Comment


Sign in with your OpenID ?


Name: (Required)

E-mail: (Required)