CMSC 22001: Software Construction Assignment 4: Test suites

Due: Feb 1, 2006 @ 3pm

Your task is to improve (or implement...) test suite infrastructure and test suites for the previous assignment. In particular:

  1. Develop a test harness that parses files in the format below, runs the specified tests, and prints the results of the tests as specified (also below).
  2. Develop your own file of test cases.

In addition to handing in your code, you must also provide a script that runs your program, accepting a test input file on stdin and producing the output on standard output. This program must be called run-stdin-test. Be sure to supply instructions about platform, etc your programs runs on.

To get you started, we have provided some test cases:

Input test fileExpected output
placement-tests.in      placement-tests.out
field-corner-connections-tests.in field-corner-connections-tests.out
field-town-adjacency-tests.in field-town-adjacency-tests.out
scoring-tests.in scoring-tests.out

To grade this assignment, we will collect everyone test cases and run them in all implementations in a mini-tournament. You will get 1 point for each of your classmate's test cases your implementation passes and you will get 1 point for each of your test cases that fails in another's implementation.

We will post the results of this mini-tournament for everyone to see, and everyone will get all of the test files to help improve their implementations as the quarter progresses.

Note that your submitted test file must match the specification below. You are not trying to test the test harness, but instead test the rules implementation. Also, your rules checker should not be checking number of meeples on the board. That will be enforced elsewhere.

Test case file specification

At a high-level, a test case file consists of a map specification, followed by a series of tile/meeple placements. Your test infrasture must read in the map specification, construct the map, and then test to see if the tile/meeple placements are legal. (The part of the specification between the map and end-map lines must consist of legal tile and meeple placements.)

The test case file may contain multiple maps, each with its own set of tile/meeple placements; your test infrastructure must make new maps as needed to handle the additional map specifications.

The text below contains the precise spec. Compare it with the contents of the example files above, to get a sense of how to parse it (the parsing should be not be difficult to implement, just line-based regular expressions).

Blank lines and lines beginning with # are always skipped in test files. The spec contains comments (following semicolons) that explain the interpretation of the specification.

An asterisk suffix indicates that the previous element is repeated zero or more times. The vertical bar is used to indicate alternatives (ie, any of the options are legal). Text enclosed in angle brackets refers to another part of the specification, parenthesis indicate grouping, and otherwise text is literally what appears in a test file.

Multiple element on a single line are always separated by a single space; with the exception of a newline (there is no space before it).

test file :== 
  (<map> <move>*)*

map :==   ;; initial map specification
  map <newline> 
  <move>* 
  end-map <newline>

move :== tile-line meeple-line

tile-line :==
   tile <tilename> <x> <y> <r> <newline>  

tilename :==   ;; the same as the IDs on the tiles web page
 CCCCS50 | CCFC50 | CCFCS50 | CCFF50 | CCRC50 | CCRCS50 | CFCF50 |
 CFFC50 | CFFCS50 | CFFF50 | CFRR50 | CRFR50 | CRRC50 | CRRCS50 | 
 CRRF50 | CRRR50 | FCFC50 | FCFCS50 | FFFFL50 | FFRFL50 | FFRR50 | 
 FRRR50 | RFRF50 | RRRR50

meeple-line :==
   nomeeple <newline>
 | meeple <side> <index> <color> <newline>

;; coordinates. (0,0) is the upper left.
;; y increases going down and x increases going to the right.
x, y :== <pos-neg-number>

r :== ;; rotation counter-clockwise (number of steps)
  0 | 1 | 2 | 3

side :==  ;; these are relative indicies; 
          ;; that is, l indicates the left side after the tile is rotated,
          ;; not before.
          ;; c means the center (or cloister, since it only applies there)
  l | t | r | b | c

index :== ;; always zero for non-road edges and cloister
          ;; for road-edges, counts clockwise along the edge
  0 | 1 | 2

color :==
  red | blue | black | green | yellow

==============================================================

output :==
   illegal <newline>
 | legal red <3nums> blue <3nums> green <3nums> black <3nums> yellow <3nums> <newline>


3nums :==
 ;; first number after each color is points for that player for that play
 ;;   (scoring the regions that were completed by that play)
 ;; second number is number of meeples on the board for that player, after
 ;;   the meeples on completed regions have been removed from the board
 ;; third number is the additional points the player receives at
 ;;   the end of the game (for incomplete regions and fields), assuming
 ;;   that the game were over at this point.
  <number> <number> <number>


CMSC 22001: Software Construction