based on a problem published in (Spanish post)
I took the description from Wikipedia article:
The rules of Rock-paper-scissors-lizard-Spock are:
And then, I started to code the solution using TDD, in C#. You can check re result at:
The commit history reveals commit by test:
See the first test/commit: it didn’t compile. Then, it started to compile, but with red result. Then, I added the minimal code to pass the test, and refactor, and so on.
I decided to have two tests, one per permutation: testing Scissors cut Paper, and other testing Paper is cut by Scissors. I could refactor the test to have an internal method testing in both ways
The initial design was based on:
- Having an instance of Game class (the alternative was to have static methots, directly in the class)
- Having an enumeration for game options (Play.Scissors, etc…)
- Having an enumeration for the play result (PlayResult.Tie, PlayResult.FirstPlayer…)
Instead of having play result, I could put a method that compare two options, deciding which one is “greater”. Today, I could refactor the implementation to use that approach.
See the last refactor: I could leave the code as is, with if command deciding which play wins, to decide when the first player wins:
But I wrote a new way:
based on Wikipedia article suggestion:
One way to remember the rules is to remember the standard "rock-paper-scissors" ordering, where each gesture defeats the one before it, and is defeated by the one after. But then add the two novel gestures near the word they approximately rhyme with:
In this expanded list, each gesture is defeated by the following two options, and defeats the preceding two.
But I feel the previous code is more clear. Sometimes, we must decide between having a clear code vs a clever one.
More TDD katas are coming.