Practice Session 5

1. Practice Session 5 Java: Packages Collection Classes Iterators Generics Design by Contract Test Driven Development JUnit

2. Java Packages • What is Package? • Way to group related class(es) and interface(s) into one unit • Package is basically a folder. • Benefits? • Code organization • All classes/interfaces related to one topic, are put under same package name. • Allows us to resolve conflicts between class names • By splitting the same name classes into two different packages. • Controlling class visibility • protected classes are visible to other classes inside the package only • Not visible to other packages, when imported.

3. MyTest Outs1 Print2.java Print1.java Java Packages • Declaration: • Declared at beginning of class file. • Syntax: package PackageName; • Example: • Folder: Package MyTest • Sub-folder: Package Outs1 • File: Class Print1.java • File: Class Print2java • Sub-folder: Package Outs2 • File: Class Print1.java Outs2 Print1.java

4. Java Packages • How to use them? • Use of absolute path of class: • Example: MyTest.Outs1.Print1 p1; • Using import keyword: • Import class: import MyTest.Outs1.Print1; • Import all classes under package: import MyTest.Outs1.*; • Object declaration: Print1 p1;

5. Java Collection • What is it? • A (huge)package of classes: • import java.util.Collection; • Contains useful data structures: • LinkedList • Stack • ArrayList • Vector • TreeSet • PriorityQueue • And much more… Full API: http://docs.oracle.com/javase/6/docs/api/java/util/Collection.html

6. Collection Iterator • All java.util.Collection data structures return an iterator to their elements. • Iterator commands: • booleanhasNext() • Returns true if there is a next element • Object next() • Returns the next object element/advances the iterator • void remove() • Optional operator / not all iterators implement it • Removes the element returned by next

7. Using the Iterator • Example: • Print all Collection object elements: • Code: static void printAll (Collection<Integer> coll) {Iterator<Integer>iter = coll.iterator( ); //returns iterator while (iter.hasNext( )) { //checks if has nextSystem.out.println(iter.next( ) ); //returns object } }

8. Generics • What are they? • Generic data structures are data structures that allows the use of any object type. • Explicitly declare what object type the data structure is going to use upon declaration, to help finding errors at compilation time. • How? • java.util.Collection.Stack<Object-Type> stk; • Examples: • A Stack that holds Integer objects. • java.util.Stack<Integer> intStack; • A LinkedList holding Student objects: • java.util.Collection.LinkedList<Student> studentList;

9. Generics Example Stack<Cow> stackOfCows = new Stack<Cow>()Stack<Float> stackOfFloat = new Stack<Float>() Cow cow = new Cow()stackOfCows.push(cow);stackOfFloat.push(cow);

10. Design by Contract(DBC) • What? • An approach for designing software. • Expresses contract between specification and implementation. • An agreement between two parties: client and supplier. • Why? • Trustworthy documentation. • Strong support for debugging. • Facilitate code reuse. • Condition Types in DbC: • Preconditions • Things that must be true before invoking a method • No conditions on after invocation. • Postconditions • Things that must be true after invoking a method • No conditions on before invocation • Invariants • things that must be true before and after any method is invoked • Must be true immediatelyafterconstruction.

11. Design by Contract Example public interface MyCollection { /** * Remove obj from the collection * * @require !( obj == null ) * * @ensure !contains( obj ) */ public void remove( Object obj ); Precondition disallows null argument. Postconditionvarifies that method removes ALL occurrences of obj /** * @invariant size() >= 0 */ public interface Queue { Assures queue size >= 0 always!

12. Design by Contract Principles • Separate queries from commands • Separate basic queries from derived queries. • For each derived query, write a postcondition that specifies what result will be returned, in terms of one or more basic queries. • For each command, write a postcondition that specifies the value of every basic query. • For every query and command, decide on a suitable precondition. • Write invariants to define unchanging properties of objects.

13. PRINCIPLE 1: separate commands and queries Commands public void add( Object o ); public void remove(); //just a command - no result Queries public int size(); public Object head(); public boolean isEmpty();

14. PRINCIPLE 2: separate basic queries and derived queries The choice of basic queries can change as we develop contracts Basic queries public int size(); public Object head(); Derived queries public boolean isEmpty(); -- we can derive isEmpty() from size()

15. PRINCIPLE 3: specify derived queries in terms of basic queries /** * Is the queue empty? * * @ensure return == ( size() == 0 ) */ public booleanisEmpty(); -- if we know the value of size(), we also know -- the value of isEmpty()

16. PRINCIPLE 4: specify postcondition for commands in terms of basic queries /** * The first element in the queue * * @require size() >= 1 * @ensure return == elements().get(0) */ public Object head(); postcondition uses basic query .get() for its implementation

17. PRINCIPLE 5: add preconditions where appropriate /** * The first element in the queue * * @require size() >= 1 */ public Object head(); It wouldn’t make the software better to pretend that an empty queue has a head element.

18. PRINCIPLE 6: specify invariant properties /** * @invariant size() >= 0 */ public interface Queue { Aim for properties that: - help readers build correct conceptual model

19. Test Driven Development (TDD) • What? • Test cases are first implemented and only then the code necessary to pass these tests are implemented. • Why? • Code is ensured to be working perfectly without any bugs! • Main tool in java: JUnit

20. Junit - Assert methods • Each assert method has parameters like these: message, expected-value, actual-value • assertTrue(String message, Boolean test) • assertFalse(String message, Boolean test) • assertNull(String message, Object object) • assertNotNull(String message, Object object) • assertEquals(String message, Object expected, Object actual) (uses equals method) • assertSame(String message, Object expected, Object actual) (uses == operator) • assertNotSame(String message, Object expected, Object actual) • Assert methods dealing with floating point numbers get an additional argument, a tolerance. (for rounding) • Each assert method has an equivalent version that does not take a message – however, this use is not recommended because: • messages helps documents the tests • messages provide additional information when reading failure logs

21. setUp/tearDown • setUp()/tearDown() • Functions which will run before and after each test. • Example usage: • setUp(): creating new objects • tearDown(): clearing data, resetting data. • If self destruction is good enough, there is no need to implement it. • setUpBeforeClass()/tearDownBeforeClass() • functions which will run exactly once before and after all the tests. • Can be used to initialize objects which will be used throughout the tests. • Changes done in first test, can be used as input data for the upcoming one.

22. Call order of the functions

23. JUnit tests for Counterclass • public class CounterTest { Counter counter1; public CounterTest() { } // default constructor • @Before protected void setUp() { // creates a (simple) test fixture counter1 = new Counter(); } • @Test public void testIncrement() {assertTrue(counter1.increment() == 1);assertTrue(counter1.increment() == 2); } • @Test public void testDecrement() {assertTrue(counter1.decrement() == -1); }} Note that each test begins with a brand new counter This means you don’t have to worry about the order in which the tests are run

24. Test Driven Development Cycle • Write the tests and for each Object Under Test (OUT): • Define interface • Define contract for each method • Specify invariant for the object, and for each method, pre and post-conditions. • Write the code so it will pass the test • Run tests • Refactor! • Improve the code, more efficient, less repetition, better looking.. • Repeat http://www.thecoadletter.com

25. Junit - Example • Interface: package spl.util; /** * All objects are of type T. Contents are ordered in Last-In-First-Out order. */ public interface Stack<T> { /** * add the object at the top of the stack. (This is a command.) * @paramobj * any non null T object to be added to the stack * @pre: none. * @post: this.isEmpty()==false * @post: this.pop(); this==@pre(this) * @post: this.pop()== @paramobj */ void push(T obj);

26. /** * remove the top object from the stack and returns it. * @return the topmost object on the stack * @throws Exception in case the stack is empty * @pre: this.isEmpty()== false; * @post: none. */ T pop() throws Exception; /** * @return True if the Stack is empty, or False if the Stack contains at * least one {@link Object}. * @pre: none. * @post: none. */ booleanisEmpty(); }

27. Create Class StackImpl package spl.util; public class StackImpl<T> implements Stack<T> { public void push(T obj) { } public T pop() throws Exception { return null; } public booleanisEmpty() { return false; } }

28. Creating a Test Case package spl.util; import static org.junit.Assert.*; import org.junit.After; import org.junit.Before; import org.junit.Test; public class StackImplTest { Stack<Integer> stack; @Before public void setUp() throws Exception { this.stack = new StackImpl<Integer>(); } @After public void tearDown() throws Exception { } Before -> run before each test After-> run after each test

29. @Test public void testPush() { fail("Not yet implemented"); } @Test public void testPop() { fail("Not yet implemented"); } @Test public void testIsEmpty() { assertEquals(true, stack.isEmpty()); } } • What happens when we run the tests? • All 3 tests fail: • testPush and testPop because the methods are not implemented. • testIsEmpty since isEmpty returns false, even though the stack is empty.

30. Add implementation to isEmpty() to pass the tests. • Implement other tests and add the implementation of the methods they test to pass them. • Change the interface to include public void remove() and public T top() in addition to pop(), and implement pop() using remove and top, to separate queries from commands. • And so on….