Modify the Person class from the Java Tutorial so that it is immutable, and create a JUnit test class for it called PersonTest.java. Both classes should reside in the package "person". Your code should pass all of your unit tests, which should cover all statements and conditions in your code, and your code should pass all of the tests in Web-CAT. Your source code (but not the tests) should also meet all the Web-CAT style guidelines. You may submit your code to Web-CAT as many times as you like before the deadline. Walkthrough of the Entire Homework Dr. K provides a walkthrough of the entire mini-project in his videos: A Tour of the Person Class from the Java Tutorial (1 video) Making the Person Class Immutable (6 videos) Unit Testing the Immutable Person Class (5 videos) Note that Web-CAT style guidelines have been ignored in these videos. You will have to fix the style problems in your submission, including adding Javadocs to the Person class. You can do this as you follow along with the video or any time after. Important Epilogue to the Videos After following along in all the videos, your Person class will still have a few minor structural issues that will need to be resolved in order to pass all the Web-CAT tests: In the areAnyNull() and areAnyInvalid() helper methods generated by Eclipse, the parameter names chosen by Eclipse are exactly the same as the names of the instance fields, which is considered a bad practice (and rejected by Web-CAT). There are two ways to fix this, with the second option being much easier than the first: Option 1 - You can refactor the parameter names to be different (such as renaming "name" to "nameX"). To do this, place the cursor within the "name" parameter of the areAnyNull() method signature, type Alt-Shift-R, and change the name of the parameter. This should change all instances (even in your Javadocs, if you've added them already) for that method. Repeat this action for each of the other parameter names within the areAnyNull() method signature, and again for all parameter names within the areAnyInvalid() method signature. Option 2 - You can reintegrate the methods you extracted during the video, placing the code back into the constructor. To do this, place the cursor within the call to areAnyNull() within the constructor, and type Alt-Shift-I (that's the letter "i") to "inline" the method and click OK. Repeat this action for the call to the areAnyInvalid() method. The Person constructor throws NullPointerException if any parameter is null, but Web-CAT considers it a bad practice to explicitly throw this exception. It can indeed be confusing in some instances, but it's certainly not a bad practice in general. However, we need to pass the Web-CAT tests, so you must change the constructor to throw a new IllegalArgumentException instead. As a result, you will also need to update the "expect=" annotation for several of your test methods accordingly, from NullPointerException.class to IllegalArgumentException.class. Finally, within the equals() method generated by Eclipse, the last if() statement is actually redundant, and Web-CAT will reject it as such. The code is perfectly acceptable as it is, and arguably more readable. However, we again must appease Web-CAT. To do so, you'll need to change the following two lines: if (!emailAddress.equals(other.emailAddress)) { return false; } return true into this one line instead: return emailAddress.equals(other.emailAddress); The code is now technically less redundant, but most developers would probably prefer the original form as more readable. After making these changes, your code should still pass all the test methods in PersonTest, and you should still have 100% code coverage from EclEmma. Once you've addressed all the style issues as well, your project should receive 20/20 from Web-CAT.