Make sure that the names of your methods match those listed above exactly, including capitalization. The number of parameters and their order must also match. The best way to ensure this is to copy and paste. Our testing will be expecting those method name names and parameters, so any mismatch will fail during our testing. Parameter names will not be tested --you can change the parameter names if you want.

Each method must be preceded by an appropriate specification, as a Javadoc comment. The best way to ensure this is to copy and paste. Note that a precondition should not be tested by the method; it is the responsibility of the caller to ensure that the precondition is met. As an example, in method isMotherOf, the method body should not test whether fm is null. However, in function areSiblings, the tests for fm1 and fm2 not null MUST be made.

The number of children of a newly created person is 0. Whenever person P is made the mother or father of another person, P's number of children should increase by 1.

It is possible for person P1 to be P2's mother, and visa versa, at the same time. We do not check for such strange occurrences.

Your method bodies should have no if statements. Your method bodies should contain only assignments and return statements. Points will be deducted if if statements are used.

Class KinPersonTester

How do you know whether class KinPerson that you are designing is correct? The only way you can be sure is to test it, to see if it does what it is supposed to do. It is not enough simply to try out your class KinPerson in the interactions pane. Every time you write a method for your class KinPerson, you should also write a couple of tests for it. And run your collection of tests frequently to make sure that everything works correctly.

Class KinPersonTester will contain your JUnit test suite; it will perform these testing tasks for you. Make sure that your test suite adheres to the following principles:

• For each method in your class KinPerson, your test suite should have at least one test case that tests that method.
• The more interesting or complex a method is, the more test cases you should have for it. What makes a method 'interesting' or complex can be the number of interesting combinations of inputs that method can have, the number of different results that the method can have when run several times, the different results that can arise when other methods are called before and after this method, and so on.
• Test very basic methods early in your test suite; then move on to more complex ones. (Make sure that car parts work on their own before you take the whole car for a test drive.)
• Don't try to test too many things in a single test case. Each test case should test only a couple of conditions.

Remember that if you change static variables in an early test, they will retain their values in later tests. Also, the tests are not necessarily run in the order in which you list them in your test suite. So when testing static variables, record their initial value at the beginning of the test, and test that the change in the value is what you expect.

Hints and Tips

• We suggest that you proceed as follows.
• First, declare the fields in class KinPerson, compiling often as you proceed.
• Second,
  • (1) Write the first constructor and all the getter methods of class KinPerson.
  • (2) Put a method in class KinPersonTester that tests whether the first constructor and all the getter methods work.
  • (3) Check that the first constructor and all the getter methods work as required. Don't go on to the next step until this is done.
• Third, for the second constructor, perform the same three steps you did for the first constructor.
• Fourth, write each of the setter methods, add a method in KinPersonTester to test them, and test them.
• Fifth, write each of the comparison methods, add a method in KinPersonTester to test them, and test them.

At each step, make sure all methods are correct before proceeding to the next step. When adding a new method, cut and paste the comment and the header from the assignment handout.

• Submit only files that end with the .java. Be careful about this, because in the same place as your .java files you may also have files that end with .class or .java~. but otherwise have the same name. In particular:
  • Microsoft operating systems hide file extensions by default. Change this so that the extensions ALWAYS appear! Don't let Microsoft tell you what to do.
  • DrJava creates "backup files", which means that you will see file names like "KinPerson.java~". The ~ indicates that the file is a backup file, which happens to be an older version of your program.

Since .class files cannot be read by TAs or run with our testing programs, submitting the wrong files creates havoc with grading your assignment. Every year, a half-dozen students submit the wrong file. Don't do it!

• Do not use if statements when completing this assignment. For boolean expressions the && (AND), || (OR), and ! (NOT) operators are sufficient to implement all the methods shown above. You will lose points for using if statements.
• Some of the KinPerson methods can be implemented easily by using other KinPerson methods that you have already created. Look for these cases, and take advantage of them as much as possible.
• Methods substring, toUpperCase, and toLowerCase in class String may be useful.
• Remember that a String literal is enclosed in double quotation marks and a char literal is enclosed in single quotation marks.
• Use method .equals to compare objects (including String objects) for equality and == to compare primitive values for equality.
• Only object variables can have the value null. So comparisons between primitive types and null are not legal.
• To create a JUnit test suite, select menu item File ->�New JUnit Test Case, and then replace the testX method with many methods that test your KinPerson functionality.