Lab 11: Testing Amazons

A. Introduction

Today you will start testing Project 2: Amazons. If you have not already, take a look at the spec here.

B. Lab

In this lab, we will go over how to test your project. There will be nothing to submit for this lab, and feel free to take this lab section as time to ask your TA and academic interns questions about the project or material for the upcoming midterm. The relevant file will be under your lab11 folder. Feel free to use the tests that you write in this lab as part of the tests you submit for your project.

C. Unit Testing

While we suggest you write unit tests for most or all of the methods you implement, we will be focusing on writing tests for the two iterators in your Board class: ReachableFromIterator and LegalMovesIterator.


In, we provide you with a test that you can use to test your reachableFrom method in your Board class. The test begins by initializing a new Board based off of reachableFromTestBoard, placing Pieces in that Board, and then calling reachableFrom on one of the placed white pieces. It then iterates through all the returned Squares and ensures they exactly match all the Squares contained the expected output reachableFromTestSquares without duplicates. Note that this test may have to be changed to work with your Board implementation, e.g. if you changed function signatures, which is completely fine.

Here are some considerations I took when I wrote this test:

  1. The number of Squares that are reachable from a Square may be very large. Let's limit this by choosing restrictive placements of our Pieces.
  2. The Board I created does not really look like a likely game state, but it does not matter too much because we are testing the functionality of one specific function.
  3. Despite (2), we still need to test "typical use" for this function, i.e. all the "cases" that might arise. Cases I covered included:

When you write your own unit tests, it is a good idea to think of many different use cases of your functions and where your functions could break. Can you think of other cases that you should be testing for this function? Try writing another test for reachableFrom that accounts for those.


In we also provide you with a skeleton to write your own test for the legalMoves. Try creating your own Board and address considerations similar to those from ReachableFromIterator as well as anything else you come up with. Ask your TA or an academic intern if you're not sure what cases to consider.

D. Integration Tests

To obtain the proj2/testing/test-amazons file to run your integration tests (if you do not have it), first commit all your changes and then run:

git fetch shared

and then

git merge shared/proj2

See the project spec as well as the provided example testing files under proj2/testing in your repo for more information on how to use this.

These tests are useful to see that your entire game is working - the integration tests model a game being played on standard input. simulates a manual white player and a manual black player, taking turns making predefined moves until one of them wins on the 13th turn. simulates an automatic white player and an automatic black player playing until one wins. and also simulate an automatic white player and an automatic black player playing until one wins. This uses two programs instead of one.

Some suggested ways of writing more tests:

  1. Play an entire game against the staff Amazons program, and replicate all your moves and the staff moves as manual players in an integration test. Make sure that you are able to run through the whole sequence of moves without errors.
  2. Observe a game between two automatic players in the staff solution. Replicate all but the last couple of the moves in a test, and then make both your players automatic. Does you AI find a similar win? It is possible that it does not, and that could also be fine (why?). In that case, does the game finish in approximately the same number of steps?

E. Summary

That's it! There will be nothing to submit for this lab.