7 — The Clean Up 🔗 ℹ

Due Thursday, 02 November 2023, 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 Planning/;

• for the (Re)Design Task, place changes.md into Planning/

• for the Testing task, place xgames 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 the TAs/reviewers 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 a 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 — Games!; the referee component and the player directory should already implement the functionality.

Required Revisions While you clean up your code, change your program so that the bonus for placing a Q could be set to 8 and the one for finishing the game could be set to 4 for the next milestone and even different values later on.

Pedagogy Implementing this change 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.

Note The decision has been made. Your answer will not influence the choice.

Testing Task Create a test harness named xgames. The harness consumes its JSON input from STDIN and produces its results to STDOUT. Create ten tests ([0-9]-{in,out}.json) 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).—Constraint No test file may exceed the size limit of 40Kb.

The inputs of xgames consist of a JState followed by aJActors array of JActors. 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 names of the winner(s) and drop-out(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 (string<=?) JNames, of winners and (2) the second the event-sorted JNames of dropout players, meaning the drop-out list enumerates the names of the player in the order in which they got kicked out.

The referee kicks out a player for the specified forms of misbehavior during any interaction. Once a player is kicked, the referee acts as if it had never been a part of disappeared from the game on the spot and it is reported as a misbehaving player. (Why?)