Geoff Bones

24 February 2014

Code kata 2: Amaze me

The kata

You are given a program which is capable of traversing 2D mazes. However, the solution isn’t perfect and fails to find the exit in certain types of mazes. Moreover, the current solution is messy, doesn’t follow any sensible coding principles (e.g. SOLID) and is completely untested.

The input to the program is a text file representing a maze. Two mazes are provided as examples in the zipped folder. maze1.txt is an example of a maze where the existing solution succeeds in finding the exit, and maze2.txt, maze3.txt and maze4.txt are examples of where it fails.

Currently the program only outputs the x,y position of the dumb maze walker at each step.

The code is available at https://github.com/geoffbones/CodeKatas.

The task

Your goal is to modify this program to work in all the example mazes, in two steps:

1. Refactor the code. It should be easy to read, follow the SOLID design principles and be sensibly unit tested.

2. Extend the program to add a second maze walker which can find the exit in all the example mazes. The existing maze walker must continue to work, even with the addition of your new and improved walker.

You should print out some information to the console for each step made by your entity. Bonus points for making it easy to see what’s going on. Example possible output in output1.txt.

Constraints

• The only valid movements in the mazes are up, down, left and right. You can’t move diagonally.
• Both maze walkers, new and old, should be demonstrably correct through unit testing.
• You must not change the technique the existing walker uses to traverse the maze, i.e. the existing maze walker must traverse the maze in the same sequence of steps after your refactorings.
• You should version control your changes so that we can view your approach to working with the solution in the discussion group.

How did it go?

All the pairs who attempted the kata focussed on refactoring the code to make it more SOLID rather than using tests to drive the direction of the work. One group had come up with separate classes to implement the walking strategy and walking function, which seemed to us to be a nice distinction.

The great thing was that everyone had managed to find small refactorings, checking in often. Mostly they found they could rely on ReSharper and only occasionally had to refactor by hand.

One group hadn’t made much progress, and they put this down to being too cautious about adding tests at the start before starting to change the code.