Code dojo for test-driven development

This content is 10 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

Every now and again, I think it would be great to do some coding, to give up this infrastructure stuff (or at least to give up the management stuff) and solve problems programmatically for a living.  Unfortunately, I also have a mortgage to pay, and certain expectations on living standards, so rewinding my career 20 years and starting again is probably not an option right now…

Even so, I took a C# course on PluralSight and, last month, I attended the Code Dojo that my colleague Steve Morgan (@smorgo) was running for some of the developers in Fujitsu’s UK Microsoft Practice.

Dojo is a Japanese word that means “a place of the way” with various explanations including a place where a group of people stay to discipline themselves.  So, it follows that a Code Dojo is a place where a group of software developers come together to be enlightened.

Our Code Dojo focused on a Kata, which is another Japanese term that literally means “form” – i.e. describing patterns of movements practiced solo or in pairs.  In this case, the pattern that we followed was one of Test Driven Development (TDD).  We used TDD to implement a software solution to a given set of requirements but, like all projects, the requirements start off incomplete and there are new requirements received at each stage of the project.

We each took it in turns to write code (even me), with the rest of the group observing and offering help where necessary.  The principle of TDD was used to write unit tests that are machine-executable expressions of requirements.

First, we wrote a test for a single requirement and then attempt to run it.  It should fail because the requirement isn’t implemented so we wrote just enough code to satisfy the requirement (and no more).  The next step is to run all tests and, if any fail, fix the failing tests or the implementation until everything works.  Finally, we refactored the code to make it more maintainable and supportable.

Very quickly, we had grasped the TDD mantra of “red, green, refactor” – i.e. at least one test fails, fix the code to pass the tests, then improve the code but tests must still pass.

The event was over all too quickly, and we ran out of time, but it was certainly worthwhile – and a great education for me.  we used C# and Visual Studio but really you could use any language to apply the principles and I really should give it another go at home.

Steve’s next Code Dojo is today but I can’t be there as I’ll be cycling to Paris as you read this (and, even if I wasn’t, I’d need to be at a management meeting!). Hopefully there will be more soon and I can continue my education…

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.