Hangman is a little game often played by pupils during math lessons without the teacher knowing. The rules are quite simple: The game master thinks of a word or phrase. The players try to guess the solution in a letter-by-letter fashion. For any bad guess, the game master adds another piece to a drawn gallows, complete with unfortunate hangman and other accessoires. When the gallows is fully constructed, the players lose. Obviously, players win if they are able to correctly solve the puzzle before.
Because of its simplicity, hangman is ideally suited for learning test-driven development or as a task for code dojos. Try to write classes and functions to handle the game logic. These features should be designed to be easily usable in an actual game application.
Continue reading “Code Dojo: Hangman”
In an earlier article I discussed the merits of unit tests. In essence, unit tests are pieces of code which assert that your production code works as intended. With a sufficient amount of unit tests it is possible to refactor your production code at any time, because the safety net of knowing when you broke something gives you courage.
Typically, programmers write code and test it afterwards. Code which is not easily unit testable is not tested or integration tested. Execution paths are overlooked, boundary cases get ignored. There is not much safety for future changes, because there is no machine-executable specification of how less well-known regions of the code are supposed to behave. Enter test-driven development (TDD).
Continue reading “Test-driven development”