For our Software Craftsmanship session at Coolblue this week I decided to run a style of kata that I had developed in New Zealand but had not had the opportunity to run here.
Our Software Craftsmanship sessions had until recently always been focused on C#, after all that’s what most of us back office developers are using, but recently I’ve started inviting the front end developers to our sessions as well.
Last week was our first session where we had Java Script, PHP and C# all being used for kata practice, which was great to see, especially since I haven’t used PHP for about 10 years and was amazed that it actually had a test framework, runner etc…
So, the type of exersize I ran for this weeks session was what I like to call “Hot Swap” katas and the actual exersize was to implement a Sudoku move validator.
The basic premise is that everyone brings a running test written in whatever language they are comfortable with. Everyone starts implementing the same kata then after a 10 minute interval everyone has to stop, mid keystroke and immediately swap to the next keyboard on their right.
You are allowed to ask some basic questions of the person who has just be “bus factored” like “how do I run your tests in language XYZ” but you can’t talk about implementation detail and what they were thinking, you need to figure that out from the tests.
The best thing I like about this type of kata is how it really highlights a few things ;
Up Front Design
As much as I love TDD it does highlight that you need to do some up front design, scoped appropriately to the user story at hand. There are a lot of times where I see people pick up a story and immediately start slinging code. This is ok if your doing the Mikado method (another passion of mine) and intend on throwing all the code away and recording your experimentation results, but sometimes just taking 30 minutes to an hour to think outside-in how the story is going to be implemented can lead to some insights that are not immediately obvious.
Outside In / Top Down
It highlights how with TDD you want to try and start from the outside boundary of your feature as this makes it easier to understand when you swap keyboards as the tests will often describe overall expected behavior better. Quite often in TDD the biggest mistake is starting from the bottom, smallest detail and building that first then working your way up.
Test Naming / Design
TEST NAMING / DESIGN !!! The main thing this exersize highlights is how critical the naming of a test is ! Nothing will slow you down more or potentially mislead you if someones test names are too vague or generic.
In one of the implementations during our kata I ran into some parameterized tests that were tpassing in the value to be passed to the method AND the asserted result as a boolean. The test was attempting to verify if the number was within range to be allowed in a Sudoku cell, but passing all the values into a test named “CanPutNumber_ShouldAllowValidNumbers” is loosing the opportunity to have some more specific tests.
I would always suggest in these situations where you have a parameterized test that also passes in the assert value, you actually have multiple requirements that are better represented as individual tests.
The very last test I might make parameterized and have two values, 1 and 9
In conclusion, the kata worked out really well. Not only did we had Python in the mix this time, which I used quite extensively a few years ago but was amazed how much I had forgotten, but we also had the difference in IDE’s (Visual Studio versus Rider) and Mac laptops, which was quite “educational” as well.
If you run code katas, give this one a try and let me know how you find it !