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:

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 — The Observer; the referee component and the player directory should already implement the functionality.

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.

(Re)Design Task The co-CEOs are considering changes to the rules and would like to know from their development team how difficult it would be to accommodate one or all of the following changes:
  • blank tiles for the board

  • use movable tiles as goals

  • ask player to sequentially pursue several goals, one at a time

Study the impact of each change on your code base. Rank it on a scale of 1 (extremely easy) to 5 (extremely hard) and explain your choice with two or three complete sentences.

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).—Constraint No test file may exceed the size limit of 20Kb.

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.

Here are the relevant data definitions:

    A BadPlayerSpec is a JSON array of PS and BadPS arrays.


    A BadPS is a JSON array of three (3) elements:

      [Name, Strategy, BadFM]


    CONSTRAINT The names of any two different PSs must be distinct.


    A BadFM is one of: "setUp","takeTurn","win".


    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.