CMPE212 – Stuff… Assn 2 due this Friday. Winter 2018 Winter 2018 CMPE212 11/29/2018 CMPE212 – Stuff… Assn 2 due this Friday. Winter 2018 CMPE212 - Prof. McLeod Prof. Alan McLeod

Today WaiterData – another Encapsulation Example. Debugging. JUnit Testing. Winter 2018 CMPE212 - Prof. McLeod

Another Encapsulated Example The problem on the next slide – “WaiterData” - was a quiz from several years ago (written on paper!). Let’s read over the problem and then look at the solution. This solution has some extra stuff!: Javadoc comments The exception class toString, clone, equals Winter 2018 CMPE212 - Prof. McLeod

Write the code for a mutable encapsulated class called WaiterData Write the code for a mutable encapsulated class called WaiterData. This class will use the IllegalWaiter exception, but you do not have to write this exception class – you can just assume that it already exists. (Let’s write it anyways!) WaiterData is designed to hold the daily sales for a month for a particular waiter. The class will hold two attributes, a String for the name of the waiter and an array of type double for the actual daily sales values. The String must have a length of 3 or more to be legal. The array must have a size between 5 and 31 inclusive. Each individual value in the array must lie between 0 and 500 inclusive. You may assume that neither argument will ever be null. Write a two parameter constructor for WaiterData. WaiterData must have a mutator for each attribute and must throw the IllegalWaiter exception if an attempt is made to create an illegal WaiterData object or if an attempt is made to set an attribute to an illegal value through either mutator. Write accessors for both attributes. Finally, write a compareTo() method for your WaiterData class. Comparison is based on the total amount of the sales array. If the supplied WaiterData object has had a higher sales total then return -1. Return 1 if the supplied object has lower total sales and zero of both totals are equal to within a dollar. Do not write any other public methods – you do not need a toString(), clone() or an equals() method. (Let’s write them anyways!) Winter 2018 CMPE212 - Prof. McLeod

Debugging Sometimes a mental “walk-through” of your code is not enough to figure out an error. With the debugger you can run to a breakpoint, stop your program and then execute one line at a time while watching the call stack, variables and custom expressions. Let’s fix UseDebugger.java Winter 2018 CMPE212 - Prof. McLeod

Debugging, Summary See “Java development users guide” > “Concepts” > “Debugger” and “Java development user guide” > “Getting Started” > “Basic tutorial” > “Debugging your programs” in the Eclipse help system. Place one or more breakpoints in your edit window. Run in debug mode. Use the “step” choices. View the method call stack, variables, and use expressions if needed. Winter 2018 CMPE212 - Prof. McLeod

Testing Until now “we” have used another class with a main method to run tests on the class we have “harnessed” for testing. See TestHalloween4.java and TestHalloween5.java for example. JUnit is a framework designed for this kind of work and it is very easy to use in Eclipse. Winter 2018 CMPE212 - Prof. McLeod

JUnit Testing Best reference is junit.org See the links in the centre column and the API docs. For use in Eclipse see: “Java development user guide” > “Getting Started” > “Basic tutorial” > “Writing and running JUnit tests”. Winter 2018 CMPE212 - Prof. McLeod

JUnit Testing in Eclipse In the project containing the class(es) you wish to test, add a Testing class by choosing “New JUnit Test Case”: Name the class and choose the classes to be tested. Choose extra stubs, if needed. Allow the addition of the JUnit library to the Build Path, if prompted. Winter 2018 CMPE212 - Prof. McLeod

JUnit Testing in Eclipse, Cont. Next, let the wizard create test method stubs in your testing class for all methods you wish to test: Winter 2018 CMPE212 - Prof. McLeod

JUnit Testing in Eclipse, Cont. Fill in the method stubs with tests. You can have multiple tests in a method or multiple methods or both, as required. You could end up with hundreds of tests, just for one object! See TestQuiz1MethodsWizard.java and TestQuiz1Methods.java. Using assertArrayEquals. Winter 2018 CMPE212 - Prof. McLeod

Assertions Use (expected, actual) or (String, expected, actual): assertArrayEquals() assertEquals() assertFalse() assertNotEquals() assertNotNull() assertNotSame() // for objects assertSame() // for objects assertNull() assertTrue() Winter 2018 CMPE212 - Prof. McLeod

Another Example See TestWaiterData.java for more assertions in use as well as testing to see if an exception is thrown. Winter 2018 CMPE212 - Prof. McLeod

assertThat() Takes a Matcher<T> object for its second (or third) parameter. Possible object types: AllOf, AnyOf, BaseMatcher, CombinableMatcher, CustomMatcher, CustomTypeSafeMatcher, DescribedAs, DiagnosingMatcher, Every, FeatureMatcher, Is, IsAnything, IsCollectionContaining, IsEqual, IsInstanceOf, IsNot, IsNull, IsSame, StringContains, StringEndsWith, StringStartsWith, SubstringMatcher, TypeSafeDiagnosingMatcher, TypeSafeMatcher Winter 2018 CMPE212 - Prof. McLeod

assertThat(), Cont. For example (from JUnit.org): And, there is a: assertThat("albumen", both(containstring("a")).and(containsString("b")) And, there is a: import static org.hamcrest.CoreMatchers.*; In the JUnit API docs look up this class for a list of these useful methods. Winter 2018 CMPE212 - Prof. McLeod

assertThat, Cont. Note that the order is different - the actual comes first followed by the expected. You can still have a String message as the first parameter. You can build more sophisticated assertions with this method. Winter 2018 CMPE212 - Prof. McLeod

Another Example See TestHalloween6.java Has more assertion methods including assertThat. And it tests to see if exceptions are thrown by using: @Test (expected=IllegalHalloweenException.class) Winter 2018 CMPE212 - Prof. McLeod

No try/catch Don’t bother with try/catch blocks. If you are testing code that has a throws decoration, then just have your unit test method throw Exception to satisfy the compiler. If an exception is thrown unexpectedly (a run-time error!) you will get a different kind of failure notice in the report. Note that the testing does not stop! Winter 2018 CMPE212 - Prof. McLeod

Test Suites You can combine separate JUnit testing classes into a single suite and run them all at once. In Eclipse, go “New”, “Other”, “JUnit”, “JUnit Test Suite”. Specify the src folder location for the existing testing *.java files and choose the ones you want to include in the suite. See AllTests.java. Winter 2018 CMPE212 - Prof. McLeod

Advantages Tests are all separate from the code being harnessed. Very easy to add tests. Running tests is very simple and fast. Results are nicely summarized and you can zoom in on failed tests easily and get some decent diagnostics. Tests can be run on remote classes on a server, for example. Winter 2018 CMPE212 - Prof. McLeod

Designing and Running Unit Tests Start by testing the most concrete independent methods first. Then test the methods that depend on these ones. Then test classes. Then test systems. Winter 2018 CMPE212 - Prof. McLeod

Designing and Running Unit Tests, Cont. You will need to write stub and driver code as required in the testing classes. Stub code substitutes something “fake” to a method that depends upon it. Driver code simulates code that uses the method being tested. Keep the stub and driver code simple so that errors can only come from the harnessed code, not the testing code. Winter 2018 CMPE212 - Prof. McLeod

Designing and Running Unit Tests, Cont. Start with tests that easily fall into the normal, expected range of inputs. Few or many? Use test generator tools? Create more tests for inputs that you suspect are related to each other. Choose tests for inputs that are just barely legal. Choose tests for inputs that are just barely illegal. Choose tests for inputs that are way out there! Make sure you exercise all the code being harnessed. Hundreds or thousands of tests! Winter 2018 CMPE212 - Prof. McLeod

Designing and Running Unit Tests, Cont. Keep all tests unless you have deleted some of the methods/classes that you were testing. You can even leave these in with a “fail” call. Fixes applied to some methods can invoke a ripple effect, causing previously passed tests to fail. In a team effort always run (and pass) all of your unit tests before committing your code to the repository. Winter 2018 CMPE212 - Prof. McLeod

Unit Testing You can never test all possible input conditions. Unit testing doesn’t prove that you code is without errors, but you can end up feeling pretty good about your code if it passes all tests. Winter 2018 CMPE212 - Prof. McLeod