1. 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

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

3. 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

4. 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

5. 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

6. 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

7. 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

8. 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

9. 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

10. 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

11. 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

12. 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

13. 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

14. 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

15. 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

16. 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

17. 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

18. 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

19. 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

20. 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

21. 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

22. 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

23. 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

24. 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

25. 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