TDD Kata (3): Tic-Tac-Toe-Tomek

Two weeks ago, I participated of the pre round of Google Code Jam. Exercise A was TicTacToeTomek:

Problem

Tic-Tac-Toe-Tomek is a game played on a 4 x 4 square board. The board starts empty, except that a single ‘T’ symbol may appear in one of the 16 squares. There are two players: X and O. They take turns to make moves, with X starting. In each move a player puts her symbol in one of the empty squares. Player X’s symbol is ‘X’, and player O’s symbol is ‘O’.

After a player’s move, if there is a row, column or a diagonal containing 4 of that player’s symbols, or containing 3 of her symbols and the ‘T’ symbol, she wins and the game ends. Otherwise the game continues with the other player’s move. If all of the fields are filled with symbols and nobody won, the game ends in a draw. See the sample input for examples of various winning positions.

Given a 4 x 4 board description containing ‘X’, ‘O’, ‘T’ and ‘.’ characters (where ‘.’ represents an empty square), describing the current state of a game, determine the status of the Tic-Tac-Toe-Tomek game going on. The statuses to choose from are:

• “X won” (the game is over, and X won)
• “O won” (the game is over, and O won)
• “Draw” (the game is over, and it ended in a draw)
• “Game has not completed” (the game is not over yet)

If there are empty cells, and the game is not over, you should output “Game has not completed”, even if the outcome of the game is inevitable.

An input file can be downloaded with different board positions, and our program should generate an output file with the results: X won, O won, tie, or the game is not finished, yet.

I wrote my solution using TDD, you can see the result at:

https://github.com/ajlopez/TddOnTheRocks/tree/master/TicTacToeTomek

The commit history, with test granularity:

https://github.com/ajlopez/TddOnTheRocks/commits/master/TicTacToeTomek

It was a simple exercise, and well adapted to TDD. Google accepted my solution to a small input file, and to a big one too. I should write about the other exercises (B, C, D) that are a bit more complicated for TDD:

– Each problem should be solved quickly. With TDD, you could implement an algorithm but it could be not efficient.

– The algorithm to implement is not evident, and you should write the increasing difficult input cases.

– Sometimes, given an input state, it is hard to reach (even by hand) a right output solution. Many of my attempts were rejected by Google, without much info about what is the right solution, so you must review manually each result.

Keep tuned!

Angel “Java” Lopez
http://www.ajlopez.com