Learning Python and Testing with Code Katas

For the past 4 years, and the four years of university, my main development languages have been the Microsoft languages, i.e. C# and Visual Basic, as well as Objective C recently. They’re very good languages. But for the longest time, I’ve always seen the need to learn new ‘kinds of’ languages. And for some reason, I’ve always had a fascination with Python.

Now arguing over languages is like arguing over sport. Everyone seems to have a justified opinion. The cool ruby guys have their reasons why it should be chosen over other languages. The clever Scala and Clojure guys too have their reasons, but at my level of experience and understanding, they sound like they are speaking in unknown tongues. The ubiquitous PHP guys too speak of the large number of developers and the ease of use. But I choose Python. And I don’t necessarily have a reason for it. I just like it. And I can use Visual Studio.

Like I said in an earlier post, this year I wanted to focus more on TDD, and adding unit testing to my workflows, so while learning the syntax and structure of a language, learning how to test was also a priority of mine. I had also heard about these things called ‘Code Katas’ which my software development celebrities such as Uncle Bob Martin seem to advocate for.

A Code Kata, from my understanding, is simply a small coding exercise where one writes a piece of code, that is meant to fulfill requirements set out. Tests can be used to ensure that the requirements are met by the code. I found a String Calculator code kata online which seemed to be simple enough for getting my head around the new language, while at the same time challenging enough that I don’t get too bored. The process I followed was as follows:

1. Create a new Python project in Visual Studio. This included a whole lot of other tasks like adding the Python project templates, and actually installing Python on my machine.
2. Add the String Calculator class with the Add method. This is so that my tests actually have something to call.
3. Write a test for the first requirement of the kata, calling the Add method created in the previous step. Ensure the add method causes the test to fail.
4. Implement the requirement of the kata within the Add method of the StringCalculator class. When it is implemented, the test should pass.
5. Refactor the code. This is to make it ‘clean’. The test will be the indicator of whether the refactoring has caused the code to break or not.
6. Repeat steps 3 – 5 for the other requirements of the kata.

Overall, the general workflow of writing tests then writing code is enjoyable. The constant feedback that one gets when the green for a passed test shows or when the red for a failed test shows keeps the entire process enjoyable and engaging. For the academics out there, it contributes to the Flow experience as proposed by ‎Mihaly Csikszentmihalyi.

While the theoretical model of TDD makes sense, in practice, there are some deviations from the theory:

1. Sometimes the test fails because of an error in the test and not an error in the code. One spends a really long time trying to figure out what’s wrong with the code, then finds that the test actually has a mistake. This probably gets better with experience.
2. Sometimes a test written for the first time will be green because the code already fulfills the requirement of the test. But the test should still be written so that after refractoring one can ensure that the requirement is still met.

Overall, it was a fun experience. It took longer than expected and recommended because of the learning of a new language. But overall the experience was fun.

The code from the kata can be found in my Github repository here.