1. CMPE212 – Reminders Assignment 2 due this Friday.
Winter 2019 CMPE212
4/3/2019
CMPE212 – Reminders
Assignment 2 due this Friday.
Next Quiz two weeks after Reading Week.
Winter 2019
CMPE212 - Prof. McLeod
Prof. Alan McLeod

2. Today JUnit Testing. Unit Testing in General.
Winter 2019 CMPE212
4/3/2019
Today
JUnit Testing.
Unit Testing in General.
TDD or “Test Driven Development”.
Coverage Testing (if we have time).
Winter 2019
CMPE212 - Prof. McLeod
Prof. Alan McLeod

3. 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 2019
CMPE212 - Prof. McLeod

4. JUnit Testing Best reference is https://junit.org/junit5/
For use in Eclipse see: “Java development user guide” > “Getting Started” > “Basic tutorial” > “Writing and running JUnit tests”.
Winter 2019
CMPE212 - Prof. McLeod

5. 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.
Winter 2019
CMPE212 - Prof. McLeod

6. 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 2019
CMPE212 - Prof. McLeod

7. JUnit Testing in Eclipse, Cont.
Allow the wizard to add the JUnit library to the Build Path, if prompted.
Winter 2019
CMPE212 - Prof. McLeod

8. 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. Diagnosis might be easier if you have one test per method.
You could end up with hundreds of tests, just for one object!
See Halloween5Test.java.
It contains one test that will not pass – just to show what a failed test looks like.
Winter 2019
CMPE212 - Prof. McLeod

9. JUnit 5 Assertions
Use (expected, actual) or (expected, actual, String). The optional argument is a string message that would describe what is being tested.
assertArrayEquals()
assertEquals()
assertFalse()
assertNotEquals()
assertNotNull()
assertNull()
assertTrue()
Winter 2019
CMPE212 - Prof. McLeod

10. IllegalHalloweenException.class
JUnit 5 Assertions, Cont.
Use assertThrows() to make sure an exception is thrown when it should be.
This assertion uses two arguments that are built using syntax we have not yet discussed.
The two are arguments are a Class object and an Executable object. The Class object:
Any object has a .class constant attribute that supplies the Class object. So we will use:
IllegalHalloweenException.class
to supply the Class object for the first argument, the expected exception type.
Winter 2019
CMPE212 - Prof. McLeod

11. JUnit 5 Assertions, Cont.
The second argument is the Executable object.
This will contain the code that is supposed to throw the identified exception.
It is easiest to construct this object using a Lambda Function.
Which we will discuss, just not yet!
() -> new Halloween5(badYear, numKids, temps, condition)
Winter 2019
CMPE212 - Prof. McLeod

12. Halloween5Test.java, Cont.
Uses setup and teardown methods.
Also uses assertThat (for a silly test…).
Winter 2019
CMPE212 - Prof. McLeod

13. 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 2019
CMPE212 - Prof. McLeod

14. 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.*;
See also:
Winter 2019
CMPE212 - Prof. McLeod

15. 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 2019
CMPE212 - Prof. McLeod

16. Some JUnit Annotations
Annotations are needed to help the testing framework understand the purpose of the methods in the testing class and how (and how often) they should be run:
@Test is used most often and it identifies a method that is a JUnit test. Methods without this annotation will not be considered tests, although they can be invoked from methods that are tests.
Winter 2019
CMPE212 - Prof. McLeod

17. More JUnit Annotations - Setup and Teardown
annotation with methods that will run before every test.
for methods to run after every test.
@BeforeAll runs once before all tests.
@AfterAll runs once after all tests.
Winter 2019
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 2019
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”.
This does not work properly in Eclipse and the JUnit5 instructions are not consistent! But you will not need to build a 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 2019
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.
Winter 2019
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 2019
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 2019
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 2019
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 2019
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 2019
CMPE212 - Prof. McLeod

26. Test Driven Development or “TDD”
Fall 2013 CMPE212
Test Driven Development or “TDD”
How much code can you “implement” without testing it?
I get nervous writing 20 or 30 lines without testing.
And whenever I complete a non-trivial method I test it.
You should not separate the process of implementation and testing.
Not surprising – this is a basic tenant of Agile Development.
Winter 2019
CMPE212 - Prof. McLeod
Prof. Alan McLeod

27. TDD, Cont.
Is all about writing tests while you are writing, or decomposing your code.
In fact the testing drives and leads the coding.
We need a systematic technique to create tests that ensures coverage:
Winter 2019
CMPE212 - Prof. McLeod

28. TDD, Cont. The three Laws of TDD:
You may not write production code until you have written a failing unit test.
You may not write more of a unit test than what is sufficient to cause a failure, and not compiling is a failure.
You may not write more production code than what is sufficient to pass the current failing test.
Winter 2019
CMPE212 - Prof. McLeod

29. TDD, Cont.
So, tests should be written at the same time as the production code. You are always one test ahead of what the production code can pass.
As the amount of production code grows so do the number of tests.
Testing code should be in separate files from production code.
It really helps to have some kind of framework to help organize and run these tests!
Winter 2019
CMPE212 - Prof. McLeod

30. Coverage Testing in Eclipse
Run
Debug
Coverage
Provides an easy way of seeing which lines of code have been covered by your testing code.
Winter 2019
CMPE212 - Prof. McLeod

31. Coverage Testing in Eclipse, Cont.
Let’s run Coverage on Halloween5Test.java to see if we missed anything.
Green – covered.
Yellow – partially covered. (Conditional branch(s) missed, for example).
Red – not covered.
We did miss some tests!
Winter 2019
CMPE212 - Prof. McLeod

32. Coverage Testing in Eclipse, Cont.
Getting rid of highlighting:
Click here
Uses a module called EclEmma. See:
Winter 2019
CMPE212 - Prof. McLeod

33. Upcoming Topics & Terms
Packages, Enumerated Types
Hierarchies, Inheritance, Polymorphism
Interfaces, Anonymous Classes, Abstract Classes, Lambda Functions, Inner Classes
Generic Classes
Winter 2019
CMPE212 - Prof. McLeod