Maze Walker

Level: Intermediate 30–60 min

Concepts: Refactoring

Solutions: C# | TypeScript | Python

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 code for this kata can be found at https://github.com/TDDBuddy/Maze-Walker

The program takes input from a text file representing the maze. There are two example mazes provided in the repository.

  • maze1.txt is an example of a maze where the current solution succeeds.
  • maze2.txt is an example of a maze where the existing solutions fails to find the exit.

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

Refactoring Work

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

  1. Refactor the code
    • Ensure code is covered by a characterization test before refactoring that area. You don’t want to regress and not know it!
    • It should be easy to read, follow the SOLID design principles.
  2. Branch by abstraction and extend the existing maze walker to find the exit in both example mazes
    • Enable toggling between the two implementations at runtime.

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 testing.
  • You can edit the DumbMazeWalker class, but you must not change the way in which it ultimately traverses the points in the maze. You can change the output function if you want, though.
  • You must not change the technique the existing DumbMazeWalker uses to traverse the maze, i.e. the existing maze walker must traverse the maze in the same sequence of steps after your refactorings.

Bonus

Make it easy to see what’s going on with your new maze walker log all of the maze as each step like output1.txt. Currently the program only outputs the x,y position of the dumb entity at each step.

Reference Walkthrough

This is an Agent Full-Bake kata — one commit per language, design rationale in the walkthrough. The reference implementation builds a grid maze from string-art layouts and uses BFS to find the shortest path from start to end.

Related reading

  • Product Literacy Is the New Core Engineering Skill
    Engineering treated product literacy as a 'nice to have', useful but not core. With agents handling translation from intent to syntax, the engineer's value lives almost entirely in the translation from business reality to correctly-named domain model. Product literacy is the part that didn't get automated.
  • Agents Amplify Whatever Vocabulary They Find
    Agents do not bring vocabulary to your codebase. They mirror what's already there. Strong vocabulary gets agent contributions that read like the team. Weak vocabulary gets faster mediocrity. The work you did for craft reasons just became leverage.
  • The Hidden Output of TDD Was Never Code
    The visible artifact of TDD is a passing test suite. The actual artifact, the one that compounded value over the life of the codebase, was the vocabulary the team built while writing it. The dictionary, not the regression net.