Lab 11: Getting Started with Ataxx

A. Introduction

Today you will get started on project 2: Ataxx. If you have not already, take a look at the specs here.

B. Lab

In this lab, we will go over how to test your project. Everything we discuss in this section can be found in testing/README in the Ataxx project directory. Make sure to read the file as this lab will only discuss a subset of all the testing functions that may be important to your project.

Integration Testing

As with all projects, you will need to write tests to ensure your code is correct. For Ataxx, you will need to provide both unit tests and integration tests. Unit tests can be implemented in a fashion similar to previous projects (by placing them into the UnitTest.java file); however, integration will be slightly more finicky.

Integration tests are stored in the testing folder and are run using the test-ataxx.py script. The script takes in, as an argument, a text file defining the integration test case. Text files contain lines that either insert commands into the command line and Ataxx program, or defines lines to be expected as output.

Take a look at testing/test01.inp included here for convenience:

# Trivial test of initial board.
java -ea ataxx.Main
dump
@<===
@<  r - - - - - b
@<  - - - - - - -
@<  - - - - - - -
@<  - - - - - - -
@<  - - - - - - -
@<  - - - - - - -
@<  b - - - - - r
@<===
quit


Let's step through this line by line.

• Line one is a comment. All lines beginning with a pound # or are empty are ignored by the testing script.
• The next line runs java -ea ataxx.Main to start instance of the Ataxx program from command line.
• The proceeding line is fed in as input to the Ataxx program. Here we are testing if dump was correctly implemented.
• If dump is correctly implemented then it should print out the following 9 lines. Any line @<TEXT denotes expected output from the Ataxx program. Note that expected output is white space sensitive! If you're confused about why your integration test may be failing, make sure to check your test cases for any extraneous white spaces that mess up the expected output's formatting.
• Finally, the Ataxx program is closed using quit.

This is a very basic integration test. The script has the power to run more complicated tests that you will find useful as you progress through the project.

Understanding questions

Find someone to discuss these questions with. Once you and your partner have reached a conclusion, flag a TA and explain to them the solutions for each question.

1. How do you start a game of Ataxx between two human players?
2. How might you implement the undo operation given the code you have? Why are we placing a null object onto the stack? Why are some functions undoable?
3. What is the difference between determining if a move is legal and if a player can move and where is this difference reflected in the code?
4. What does it mean to linearize the board and why might this be helpful?
5. What is the buffer for?

When coding your AI, it will be informative to provide a test case that plays an Ataxx game between two program instances. Take a look at testing/text07.inp. Answer the following questions!

1. How do we know that this test case plays a game between two Ataxx instances
2. What is the purpose of the lines @send blue... and @recv blue...

Your task for this lab will be to write and submit two integration tests. Test case 1 should do the following.

• Start the Ataxx program and set the playing board to be formatted as below.
r - - - - - b
- - - b - - -
- - b b b - -
- b b r b b -
- - b b b - -
- - - - - - -
b - - - - - r

• Set red to be the starting player and perform the move d4-f4. What should happen?
• Following the previous, make the move a7-a8. What should happen?
• Make the move d4-d2 and dump the board. What should the board look like?
• Quit the game

Write this test case and place it into the text file test-ataxx-1.inp. The second integration test will be up to your design. Write a case that tests for either an interesting edge case or a specific functionality in the program. Store this case in test-ataxx-2.inp. Finally, submit these two text files. Note that even though you wrote these in lab, they can still be used in your final project submission (hooray for getting started early)!

Running the staff ataxx

When writing tests, it might not always be clear what the correct output should be. This is why we have given you access to the staff solutions for Ataxx. You may access the staff solution by the following steps:

• SSH into your instructional account ssh -X cs61b-xxx@ashby.cs.berkeley.edu.
• Run staff-ataxx.
• Run staff-ataxx --display for the Ataxx GUI.

A quick note on running the GUI for staff-ataxx. Since you are running the GUI remotely, you will need to have X forwarding setup before hand. Macs can install XQuartz to handle this while Windows machines will need to do something a bit trickier. Check out the Piazza post here!

C. Submission

Please submit your integration tests test-ataxx-1.inp and test-ataxx-2.inp.