CS 170 Java Programming 1 Week 13: Classes, Testing, Debugging
What s the Plan? Short lecture for makeup exams Topic 1: A Little Review How to create your own user-defined classes Defining instance variables, constructors and methods Topic 2: Testing and Correctness Writing hand-crafted and JUnit unit tests No quiz or homework this week, but you must complete the IC document and there is an extra-credit assignment
Your "IC" or "Lab" Document Use Word or OpenOffice to create a new document Save the file as IC013.doc (Office 97-2003 compatible) Place on your network U: drive or on a thumb drive Put your name and today's date at the top of the sheet Title it "CS 170 Lab Exercises Week 13" Start DrJava and we'll review a few basic class concepts Copy NIM.jar from Q: and double-click it This is an extra-credit assignment using several classes Open Nim.drjava project in Nim-Project folder We are going to work the Game and Pile classes
The Game of NIM Here are the rules for our game of NIM Two players alternately take marbles from a pile Player must take one, but cannot take more than half Last player to take a marble loses Here are the classes that are already defined Nim is our "program" class with a main() method Game will contain the game-playing logic Pile controls the pile of marbles Player actually makes the decisions We'll have two kinds of players: human and computer The computer can be either smart or stupid
Review State and Data Object data is stored in instance variables or fields Defined outside of any method, but inside class private type name [ = initial-value ]; Pile class will need an instance variable for marbles Game class will need three Player fields, one Pile One Player will be an alias for each of the others Exercise 13.1: add instance variables and shoot a screenshot of each class 5
Review Initializing Objects Object fields are initialized by writing constructors Same name as class, no return type May have different constructors, different parameters Constructors should always initialize data fields Exercise 13.2: add a Pile constructor that takes a single parameter to initialize the instance variable (snap a pic) Assign the parameter value to the field Use different names, or this to refer to field Exercise 13.3: read docs and complete Game constructor
Review Encapsulation Encapsulation: objects responsible for their own data Only access to object state is through public methods Need to provide accessors and mutators to use object
Review Object Methods Methods that modify an object are called mutators Accessors return information about an object public void methodname(parameters) { // statements modify fields } public returntype methodname() { return typeexpression; Mutator } Accessor
Review Instance Methods Exercise 13.4: Let's add accessors to the Pile class getsize(): tell us how many marbles are left hasmarbles(): returns true if there are marbles left For accessors, you should add an @return to Javadoc Exercise 13.5: Now, let's add a mutator: remove(int amount): removes marbles from Pile The variable int amount is called a formal parameter For each formal parameter, add an @param tag Holds different values (actual parameters) when called
Introducing Unit Tests How do we know if we've written Pile class correctly? Don't want to wait until Nim is finished Should write independent tests to ensure it works right These are called unit tests Add a new class named PileManualTest Use ACM console program or simple console program Inside the run() method, create a Pile object Let's start with the initial value 20 Use values that let you calculate expected output easily 10
Testing the Class How do we know if the Pile constructor worked? We compare its expected value and its actual value Call getsize() and print expected and actual values Now, test two more Pile objects with different initial values Exercise 13.6: shoot a screenshot How do we know the mutator works? Call remove() (to mutate Pile), and then print the expected and actual values again Exercise 13.7: shoot a screenshot 11
Introducing JUnit Unit tests are most important testing tool you have Create instance of your class, call mutators Check expected values with actual Problem? Very time-consuming to compare values Easy to miss non-matching actual and expected values JUnit testing tool automates comparison JUnit is standard Unit Testing tool, not just for DrJava Exercise 13.8: choose File->New JUnit Test Case Name the class PileTest, save and compile Compile and Test Project
Writing Test Methods Write a separate test method for each operation void method, name starts with test, no parameters Create an object in a known state Call the method you are testing Compare the expected state with the actual state Exercise 13.9: add testpilesizezero() method Create Pile with a size of 0 Create a variable to hold the expected size Call getsize() to retrieve actual size value Call assertequals() method, passing the expected and actual values as parameters
JUnit Assertions Use assertions to compare expected versus actual Most common is assertequals(expect, actual) Here are some other useful assertions // For double or floating-point comparisons assertequals(expect, actual, tolerance) // A simple boolean expression (true or false) asserttrue(test) or assertfalse(test) // Testing for null or not null assertnull(obj) or assertnotnull(obj) Also versions that takes a string message parameter
Selecting Test Cases Positive tests: legitimate input you expect the program handles correctly All values >= 0 in a square-root program Boundary cases: also legitimate input to be handled in a trivial way 0 or the empty string may be handled as a special case Negative cases: input that you expect to fail Negative numbers, string input?
Finishing Up To complete your IC "lab" document: Read and complete the additional exercises in the lessons on Static Variables and Methods, Testing and Debugging. Submit to Blackboard when done Reading for this week: Gaddis: Finish Chapter 6, start Chapter 7 (Inheritance)