3 —
Due Thursday, 03 October 2019, midnight
Delivery Place the product of this week’s project steps into your repo as follows:
for the Design Task, place rules.md in Planning/
for the Programming Task, place board.PP in Common/
for the Testing task, place xtiles and tile-tests in a top-level directory named 3
Design Task While we studied our software architecture from the perspective of interfaces and component interaction, it became clear that the plan should have separated the referee component from the rule checker component. The former is about the mechanics of running a game; the latter is about checking the legality of player actions, which is apparently far more complex than initially assumed.
Describe interfaces for Tsuro for rule checkers. .
Keep in mind that the referee must use such a checker, the player may use one or it may decide to take its chances and play any which way it wants.
The memo must not exceed two pages. Less is more.
Tiles All external communication of your programs will use the JSON representations listed in Tsuro, Tile Types.
Programming Task Design an implementation of your board data representation, including the following operations:
one that places a player’s first tile and avatar on the board;
one that adds a tile on behalf of a player whose avatar occupies a place on the board;
one that creates a board from a bunch of initial tile & player placements;
The operation should reject placements that result in boards where tiles neighbor other tiles, tiles not placed on the periphery, and tiles where the avatar does not occupy a port that faces the board’s interior.
one that creates a state from a bunch of intermediate tile & player placements;
The operation should try to reject placements that result in boards with tile placements that couldn’t have possibly resulted from a series of turns.
As the plan points out, the board itself cannot enforce rules. Baking some basic constraints into the board’s “physical” functionality is acceptable, though. The above methods illustrate this idea with basic examples.
Testing Task Create a test harness named xtiles. The harness consumes its JSON input from STDIN and produces its results to STDOUT.
Its inputs has the shape [tile-index, degrees, port] .
Its expected outputs look like this ["if ", port, " is the entrance, ", port, " is the exit."]
As for —
Create three tests and place them in tile-tests.
Pedagogy Besides unit tests, multi-component projects also need integration tests. Such tests compose several components and run tests on the composite that exercise functions across the components. This task is a lightweight illustration of this idea.
When a milestone assignment requests such test harnesses, you should not need to add code to your solutions from the previous milestone.