In the previous post, I implemented a sudoku solver. Unfortunately, it does not work yet. Let’s fix it! Debugging the solver in the current state of the code is hard. The test fails because the expected solution is not equal to the actual solution returned, but since I have no way of visualizing the Grid it’s hard to say what the difference is. Therefore, my approach here would be to write a function to print the grids....
The code I wrote in the last post would use some refactoring. However, the tests are working, and I feel like I would be spending my time refactoring stuff that already works instead of trying to tackle the actual problem of solving a sudoku. If you read “The Pragmatic Programmer”, the authors introduce the concept of “tracer bullets”. That is, a minimal version of the application that does something useful and works end to end....
The other day, in the first post of the series, I started writing a sudoku solver with TDD. In particular, I wrote a simple Grid class to encapsulate the game’s state. I think it’s now time that we start writing a solver for the puzzle. Solver Interface As I’m trying to use TDD, I first need a test for the solver. To write a test I need to think of an interface....
I’m going to imitate Ron Jeffries. In his series of posts, Ron tried writing a sudoku solver using TDD (Test Driven Development) to see if the methodology works and what would happen. He eventually quit the project without completing it. So I am going to write a sudoku solver, posting my progress as I go along. I’m going to try using TDD and document my thought process. Let’s see where I end up, if I manage it or quit and if we can learn something new along the way....