Right, so I\u2019ve chosen my project and I\u2019m ready to begin. I\u2019ll skip past the introduction, straight to page 8 of the rulebook. The characteristics section. This is basically a class layout, nothing too heavy, so I\u2019ll start off by creating Model.cs:<\/p>\n
class <\/span>Model\n<\/span>{\npublic string <\/span>Name { get<\/span>; set<\/span>; }\npublic int <\/span>WeaponSkill { get<\/span>; set<\/span>; }\npublic int <\/span>BallisticSkill { get<\/span>; set<\/span>; }\npublic int <\/span>Strength { get<\/span>; set<\/span>; }\npublic int <\/span>Toughness { get<\/span>; set<\/span>; }\npublic int <\/span>Wounds { get<\/span>; set<\/span>; }\npublic int <\/span>Initiative { get<\/span>; set<\/span>; }\npublic int <\/span>Attacks { get<\/span>; set<\/span>; }\npublic int <\/span>Leadership { get<\/span>; set<\/span>; }\n}<\/pre>\nNothing really testable here yet. No point in testing basic getters and setters.<\/span><\/p>\nNext up is a description of the turn structure \u2013 this calls for a game manager of some sort. How about GameManager.cs, with an enum (TurnPhase)?<\/p>\n
class <\/span>GameManager\n<\/span>{\n TurnPhase <\/span>CurrentPhase { get<\/span>; private set<\/span>; }\n int <\/span>_numberOfPlayers;\n int <\/span>_currentPlayersTurn;\n}\nenum <\/span>TurnPhase\n<\/span>{\nMovement,\nShooting,\nCloseCombat,\nRecovery\n}<\/pre>\nI think I\u2019ll also add in an integer to GameManager to determine the number of players, and the number of the player whose turn it is. That should be enough to track that for now. To increment the turn onwards, though I\u2019m not sure how that will be triggered yet, I need to add some actual logic! This should have a unit test. In proper TDD fashion, the test will be written first.<\/p>\n
[TestMethod<\/span>]\npublic void <\/span>IncrementTurnPhase_RollsBackToMovementPhaseAfterRecovery()\n{\nGameManager <\/span>manager = new <\/span>GameManager<\/span>();\nmanager.IncrementPhase(); \/\/ Go to Shooting\n<\/span>manager.IncrementPhase(); \/\/ Go to Close Combat\n<\/span>manager.IncrementPhase(); \/\/ Go to Recovery\n<\/span>manager.IncrementPhase(); \/\/ Go back to Movement\n<\/span>Assert<\/span>.AreEqual(TurnPhase<\/span>.Movement, manager.CurrentPhase);\n}<\/pre>\nThis looks about right \u2013 but I\u2019ll need to give GameManager a bit of a tidy up and make things a little more accessible. Now the code to pass that test:<\/p>\n
public void <\/span>IncrementPhase()\n{\nif <\/span>(CurrentPhase == TurnPhase<\/span>.Recovery)\n{\nCurrentPhase = TurnPhase<\/span>.Movement;\n}\nelse\n<\/span>{\nCurrentPhase++;\n}\n}<\/pre>\nThat\u2019s nice and neat. But I found that without writing any code in that method, it still passes \u2013 since the turn phase is still Movement. Another test to make sure that it only increments one space will probably be in order.<\/p>\n
[TestMethod<\/span>]\npublic void <\/span>IncrementTurnPhase_MovesForwardPhase()\n{\nGameManager <\/span>manager = new <\/span>GameManager<\/span>();\nTurnPhase <\/span>firstPhase = manager.CurrentPhase;\nmanager.IncrementPhase(); \/\/ Go to Shooting\n<\/span>TurnPhase <\/span>secondPhase = manager.CurrentPhase;\nAssert<\/span>.AreNotEqual(firstPhase, secondPhase);\n}<\/pre>\nThis one does the trick. Makes sure that the phase has changed within the turn.<\/p>\n
Finally, the last couple of paragraphs on page 9 say that control alternates between players. I know from experience that there could easily be multiple players, and I want to be ready for that. So the GameManager will increment _currentPlayersTurn every time the turn finishes (after the Recovery phase), and reset the _currentPlayersTurn integer back to 1 when it exceeds _numberOfPlayers.<\/p>\n
Once more, write a test to check that it increments at the end of a turn:<\/p>\n
[TestMethod<\/span>]\npublic void <\/span>IncrementTurnPhase_ChangesPlayerAtEndOfTurn()\n{\nGameManager <\/span>manager = new <\/span>GameManager<\/span>();\nint <\/span>firstTurn = manager.CurrentPlayersTurn;\nmanager.IncrementPhase(); \/\/ Go to Shooting\n<\/span>manager.IncrementPhase(); \/\/ Go to Close Combat\n<\/span>manager.IncrementPhase(); \/\/ Go to Recovery\n<\/span>manager.IncrementPhase(); \/\/ Go back to Movement\n<\/span>int <\/span>secondTurn = manager.CurrentPlayersTurn;\nAssert<\/span>.AreNotEqual(firstTurn, secondTurn);\n}<\/pre>\nNow to test the next bit, it\u2019ll be necessary to add a proper constructor with a parameter \u2013 number of players. Here\u2019s the test:<\/p>\n
[TestMethod<\/span>]\npublic void <\/span>IncrementTurnPhase_ReturnsToFirstPlayerAfterAllHaveHadTurn()\n{\nGameManager <\/span>manager = new <\/span>GameManager<\/span>(2);\nmanager.IncrementPhase(); \/\/ Go to Shooting\n<\/span>manager.IncrementPhase(); \/\/ Go to Close Combat\n<\/span>manager.IncrementPhase(); \/\/ Go to Recovery\n<\/span>manager.IncrementPhase(); \/\/ Go back to Movement\n<\/span>manager.IncrementPhase(); \/\/ Go to Shooting\n<\/span>manager.IncrementPhase(); \/\/ Go to Close Combat\n<\/span>manager.IncrementPhase(); \/\/ Go to Recovery\n<\/span>manager.IncrementPhase(); \/\/ Go back to Movement\n<\/span>Assert<\/span>.AreEqual(1, manager.CurrentPlayersTurn);\n}<\/pre>\nAnd the code that passes both of those tests:<\/p>\n
public <\/span>GameManager(int <\/span>numberOfPlayers)\n{\nNumberOfPlayers = numberOfPlayers;\nCurrentPlayersTurn = 1;\n}\npublic void <\/span>IncrementPhase()\n{\nif <\/span>(CurrentPhase == TurnPhase<\/span>.Recovery)\n{\nCurrentPhase = TurnPhase<\/span>.Movement;\nif <\/span>(CurrentPlayersTurn == NumberOfPlayers)\n{\nCurrentPlayersTurn = 1;\n}\nelse\n<\/span>{\nCurrentPlayersTurn++;\n}\n}\nelse\n<\/span>{\nCurrentPhase++;\n}\n}<\/pre>\nAfter adding the requirement for a number of players to the other tests, all the tests so far pass. There is, as I\u2019ve been warned, more test code than real code (67 lines in GameManagerTests compared to 40 in GameManager) but seeing all those little green ticks is definitely a psychological boost. As I\u2019ve neatly finished page 9 and the \u2018Rules\u2019 section, I will start the \u2018Movement\u2019 section next time. This will have a bit more design than the fairly sparse classes here, and a bit more deliberation over where to put particular bits of code. I know a big idea of TDD is to write, then refactor, but I don\u2019t want to do too much refactoring. It could become quite a hassle, especially later in the day. We\u2019ll see when we get there!<\/p>\n
This is a learning project I am documenting in order to teach myself TDD and unit testing \u2013 as I publish this, I have already written many parts in advance but I want to know what I\u2019m doing wrong! If you see improvements or corrections, either to the code or the process, please leave a comment and let me know! Introduction to this project can be found here<\/a>.<\/em><\/p>\n","protected":false},"excerpt":{"rendered":"Right, so I\u2019ve chosen my project and I\u2019m ready to begin. I\u2019ll skip past the introduction, straight to page 8 of the rulebook. The characteristics section. This is basically a class layout, nothing too heavy, so I\u2019ll start off by creating Model.cs: class Model { public string Name { get; set; } public int WeaponSkill … <\/p>\n