7 — The Clean Up
Due WednesdayThursday, 10 November 2022, 11:59:59pm
Delivery Place the product of this week’s milestone into your git repo as follows:
for the Programming Task, place todo.md into Maze/Players/ Planning/;
for the Design Task, place changes.md into Planning/
for the Testing task, place xbad and Tests/ into a top-level repo directory named 7
Programming (Clean-up) Tasks Like all software projects, yours has accumulated a significant technical debt, partly due to the usual kinds of disagreement between your "customer" and you, mostly due to the usual deadline stress.
Your team manager has decided that the project needs to reduce this debt now that you have a new partner. This will give you a chance to work through design rationales, rewrite or document all difficult to decipher code snippets, and reassess the qualities of the code base in general.
Step 1 Compile a list of todo items and priority-rank them. Commit and push as todo.md.
For sources of problems, consider the feedback you have gotten for the past six milestones. Still-failing integration tests should get the highest priority. Also, revisit all those purpose statements, complicated methods, overly large functions, and unit-test suites about which your TAs complained.
Step 2 Work through this todo list. As you complete an item, move it from the todo list to a separate section, entitled “Completed.” Add the git commits plus the commit messages that fix the issue.
The TAs will cross-check that at the end all git commits are accounted for.
Guidance A clean-up task should always look forward, attempt to
anticipate how the software may evolve. Here we provide two explicit
prompts. The first is required code revision; the second is the design
task, which does not affect the current programming task but may affect future
tasks. Additionally, the testing task may demand “pay down” but, in principle,
it should not. It essentially asks for a minor revision of your test script from
6 —
Required Revisions While you clean up your code, relax the condition that a board must come with exactly seven rows and columns. The top-most row and the left-most column remain movable, as do all other even-numbered rows and columns.
Additionally, let’s impose the restriction that the players’ homes are distinct tiles.
So far our test framework has enforced this size condition. It did not enforce the distinctness of homes. As of the next milestone, the test framework will no longer check the size condition, but it will enforce the distinctness of homes. – This change in validity constraints does not affect code but tests.
Pedagogy These changes may point out infractions of rather basic design rules that may have significant repercussions in terms of technical debt. Think of them as simple examples.
blank tiles for the board
use movable tiles as goals
ask player to sequentially pursue several goals, one at a time
Note We have already decided which aspect of the rules to change. Your answer will not influence our choice.
Testing Task Create a test harness named xbad. The harness consumes its JSON input from STDIN and produces its results to STDOUT. Create three tests and place them in the specified Tests/ folder.
A test case always consists of given inputs and expected outputs. For this
course, a test consists of a pair of files: n-in.json, the input file, and
n-out.json, the expected output file, where n is an integer between 0
and the requested number of tests (exclusive).—
Its inputs consists of a BadPlayerSpec followed by a RefereeState. The test harness creates a series of players that are going to use the specified strategies. It then hands these players and the given state to the referee, which runs the game to the end and computes the winner(s). (The details will depend on your referee interface and data representations.)
The output is an array of two arrays: (1) the first contains the alphabetically sorted Names, of winners and (2) the second the alphabetically sorted Names of dropout players. Note Your test harness could compute the second array without running the game. The TAs know about this illegal shortcut.
|
|
CONSTRAINT The names of any two different PSs must be distinct. |
|
|
INTERPRETATION Requests a test with a player actinng badly. |
|
A bad strategy [n, s, b] a player named n that pursues strategy s |
until method b is called. When b is called, the method |
integer-divides 1 by 0 (which should raise an exception in all |
chosen languages). |
|
GLOBAL CONSTRAINT The array of RefereePlayers (in RefereeState) |
contains as many players as the BadPlayerSpec. The order of players in |
BadPlayerSpec is the same as the order in RefereeState. |
The test harness will enforce the 7 x 7 board size for this test fest, and it will not enforce the distinctness of homes.