TDD Pair Programming at University
Today was surprising day at the university. I’m taking a class called Designing Object-Oriented Software which has before been somewhat boring 7 x 90 min lectures and an exam but this year our professor hired a guy called Aki Salmi to organise 4 workshops á 4 hours. Beforehand I knew Aki is a guru and an excellent guy but I was still surprised to see how much fun studying at best could be.
The idea in the first day was to start implementing Conway’s Game of Life in Test-Driven Development (TDD) style with pair programming. For me, the TDD was a new approach – I’ve done it very little in Learn to Program: Crafting Quality Code and also in Functional Programming Principles in Scala but it has been merely a sneak peek. Pair programming on the other hand was something I had never done before. This time, we were thrown to the wolves with just a few bits of information:
Rules of Game of Life, very small stub on how to make tests with JUnit, Mockito and Hamcrest and order to create tests first and start implementing after that. At first it was of course really challenging to adopt a new way of thinking (TDD) and also a new way of doing (pair programming) especially when Aki really challenged us to think on our own and responded most implementation-related questions with something like “try it out”. Towards the end we found out that we were drifting away from TDD concept but we managed to get back on the saddle before the day ended.
First workshop of 4 hours is now behind and I programmed with a guy I’ve never written code with or even discussed about programming with but who I knew from student organisations. We were encouraged to work as pair programming ping-pong where one writes the test and another makes it pass and then we refactor together and for the next iteration we changed roles. It turned out to be a great way to stimulate new thinking and I found out that pair programming can be really fun. I had seen few presentations about pair programming and always thought it was stupid but now really trying it out it turned out to be something that really fits in to my workflow.
With three more workshops to come, I will definitely take the TDD as bigger part of my workflow on personal projects and I’m eager to learn more.
Sign up for Syntax Error, a monthly newsletter that helps developers turn a stressful debugging situation into a joyful exploration.
If you found this post interesting, consider sharing it with your community or following me on Mastodon.