OOSC – Lab 1

Welcome Object Oriented programming is first and foremost a method for software construction, whose goal is to build high-quality software in a repeatable way. Achieved by designing classes that: Correspond well to the application domain Have simple and clean interface Documented interface for future re-use and modification

Design By Contract A method of separating the concerns of the user and implementer of the class, and giving both enough information for their tasks. Work in this course will be done with Java, offers partial support for those concepts. Each class and method should be documented in Javadoc style.

Design By Contract In order to implement the principles of Design-by- Contract in Java, we will use a free tool from Man Machine Systems names JMSAssert. It works with Sun’s JDK 1.2 & 1.3 but not 1.4

Design By Contract A powerful technique for writing reliable software. Specifying the software purpose with the implementation. Key elements: Invariant Preconditions Postconditions

Design By Contract Precondition – The constraints under which the routine will function properly. Postconditions – The state of the class after the routine execution The Contract: If you call routine R() with the preconditions satisfied, R() will return satisfying the postconditions. Invariant – Always holds

When are condition checked?

JMS Syntax - Invariant Invariant May access all class members or its direct/indirect bases, including private members May appear in any JavaDoc comment Preferable in the class comment

JMS Syntax - Preconditions Precondition JavaDoc preceding the respective method May reference class members and arguments markers are conjugated (AND)

JMS Syntax - Postconditions Postconditions JavaDoc preceding the respective method May use $prev(expression) to access the value at the method entry. May use $ret to denote method’s return value markers are conjugated (AND)

Example /** !isEmpty() (top == $prev(top- 1)) $ret == elems[top] !isFull */ public synchronized Object pop() { return elems[--top]; } Precondition Postconditions

JMS Syntax - General Order has no – for complicated conditions Recursion – as expected, on every call Inner classes can access outer classes’ members Anonymous classes – specify invariant in one of its methods

Downloads & Installations Download Java J2SE SDK from (~41MB) Install into C:\Program Files\jdk1.3.1_07 Download JMSAssert 1.02 from (~1.2MB) Run the jmssetup-1.02.exe installation file Install into C:\Program Files\AMSAssert1.0

JMSAssert Installation The following lines are added to the path: REM Next two lines are added by JMSAssert SET CLASSPATH=%CLASSPATH%;C:\PROGRA~1\JMSASS~1.0\ bin\mmsclasses.jar; SET PATH=%PATH%;C:\PROGRA~1\JMSASS~1.0\bin; Copy the “ classic ” directory from “ C:\Program Files\jdk1.3.1_07\jre\bin\ ” to the directory: “C:\Program Files\JavaSoft\JRE\1.3.1_07\bin\”

Setup (cont.) Your JavaSoft directory should look like:

JMSAssert – how does it work Annotate source code with assertions Compile your code using javac (as usual) Preprocess the code using jmsassert: creates contract files ( *.jms ) and a Startup.jms file. *.jms files contain java code for the assertions. Execute using: jmsjava Startup to check assertions. jmsjava makes sure method assertions are called before/after the method invocation.

JMS Execution “ jmsassert ” – generates help text “ jmsassert –s ” – generate assertions for a class file “ jmsassert –r –s. ” – generate assertions for all class files in the directory and sub-dirs. (use for packages) “ javac ” – compile “ jmsjava Startup ” - execute and check assertions

Annotate source with assertions Preprocess to generate assertion files jmsassert –s Compile Java file javac Execute using jmsjava MyStack.java Startup.jms default_MyStack.jms default_MyStack_StackEnum.jms MyStack.class MyStack$StackEnum.class jmsjava Startup StackTest.class Stack Demo files Execution process

Notes Execute these steps form the command line! Make sure your CLASSPATH environment variable contains the current directory. Add “ CLASSPATH=%CLASSPATH%;.; ” to autoexec.bat.

An Example (MyStack) A stack with invariants, pre conditions and post conditions: MyStack.java A main file: StackTest.java Compile all.java files (using javac ) Generate JMSAssert triggers by: jmsassert –s MyStack.java Run and test assertions by jmsjava Startup StackTest You can always run your test program in by java StackTest

MyStack.java (#1) (top >= 0 && top < max) */ class MyStack { private Object[] elems; private int top, max; (sz > (max == sz && elems != null) */ public MyStack(int sz) { max = sz; elems = new Object[sz]; }

MyStack.java (#2) (top == $prev (top) + 1) && elems[top-1] == obj */ public void push(Object obj) { elems[top++] = obj; } (top == $prev (top) - 1) && $ret == elems[top] */ public Object pop() { return elems[--top]; }

MyStack.java (#3) ($ret == (top == max)) */ public boolean isFull() { return top == max; } ($ret == (top == 0)) */ public boolean isEmpty() { return top == 0; } } // End MyStack

StackTest.java class StackTest { public static void main(String[] args) { MyStack s = new MyStack(2); // Can push at most 2 elements s.push(new Integer(1)); s.push(new Integer(23)); s.push(new Integer(0)); // Precondition violation here! }

Eclipse Download and install eclipse from (simply extract to C:\Program Files\eclipse ) Instructions are under Also under

JUnit JUnit is a regression testing framework written by Erich Gamma and Kent Beck. It is used by the developer who implements unit tests in Java. JUnit is Open Source Software, released under the IBM's Common Public License Version 1.0 and hosted on SourceForgeOpen SourceIBM's Common Public License Version 1.0 SourceForge

Junit - Installation Download from UnZip to C:\Program Files\junit3.8.1 Add junit.jar to your CLASSPATH Test samples under junit by java junit.textui.TestRunner junit.samples.AllTests OR java junit.awtui.TestRunner junit.samples.AllTests

Unit testing Developers write unit tests to check their own code. Unit testing differs from integration testing, which confirms that components work well together, and acceptance testing, which confirms that an application does what the customer expects it to do. Unit tests are so named because they test a single unit of code. In the case of Java, a unit usually equates to a single class

Unit testing (cont.) A unit test is fully automated, non-interactive, and binary—that is, it either succeeds or fails. So running your code and examining its output to see if it works is not a test. Neither is writing a little "test driver" that drives your code and allows you to check logs to see if it's working correctly For years, unit testing languished in the "I know I should be doing it" category

The problem Every programmer knows they should write tests for their code. Few do The universal response to "Why not?" is "I'm in too much of a hurry." This quickly becomes a vicious cycle

An example (money.. Yeh!) class Money { private int fAmount; private String fCurrency; public Money(int amount, String currency) { fAmount= amount; fCurrency= currency; } public int amount() { return fAmount; } public String currency() { return fCurrency; }

An Example (cont.) public Money add(Money m) { return new Money(amount()+m.amount(), currency()); } import junit.framework.TestCase; public class MoneyTest extends TestCase { //… public void testSimpleAdd() { Money m12NIS= new Money(12, "NIS"); // (1) Money m14NIS= new Money(14, "NIS"); Money expected= new Money(26, "NIS"); Money result= m12NIS.add(m14NIS); // (2) assertTrue(expected.equals(result)); // (3) }

An Example (cont.) We have code (1) to create the objects We have code (2) to exercise the objects in the fixture We have code (3) to verify the result Before we can verify the result we have to digress a little since we need a way to test that two Money objects are equal. The Java idiom to do so is to override the method equals defined in Object

An example (cont.) public boolean equals(Object anObject) { if (anObject instanceof Money) { Money aMoney = (Money)anObject; return aMoney.currency().equals(currency()) && amount() == aMoney.amount(); } return false; }

An Example (cont.) public void testEquals() { Money m12NIS= new Money(12, “NIS"); Money m14NIS= new Money(14, “NIS"); assertTrue(!m12NIS.equals(null)); assertEquals(m12NIS, m12NIS); assertEquals(m12NIS, new Money(12, “NIS")); // (1) assertTrue(!m12NIS.equals(m14NIS)); }

Using TestCase subclass public class MoneyTest extends TestCase { private Money f12NIS; private Money f14NIS; protected void setUp() { f12NIS= new Money(12, “NIS"); f14NIS= new Money(14, “NIS"); }

Rewrite test cases public void testEquals() { Assert.assertTrue(!f12NIS.equals(null)); Assert.assertEquals(f12NIS, f12NIS); Assert.assertEquals(f12NIS, new Money(12, “NIS")); Assert.assertTrue(!f12NIS.equals(f14NIS)); } public void testSimpleAdd() { Money expected= new Money(26, “NIS"); Money result= f12NIS.add(f14NIS); Assert.assertTrue(expected.equals(result)); }

A static run override the runTest method inherited from TestCase and call the desired test case TestCase test= new MoneyTest("simple add") { public void runTest() { testSimpleAdd(); } }; Name the test so you can identify it if it fails

A dynamic run create a test case to be run uses reflection to implement runTest the name of the test is the name of the test case method to invoke dynamically finds and invokes the test method TestCase test= new MoneyTest("testSimpleAdd"); The dynamic way is more compact to write but it is less static type safe

Define a TestSuite and run The suite method is like a main method that is specialized to run tests public static Test suite() { TestSuite suite= new TestSuite(); suite.addTest(new MoneyTest("testEquals")); suite.addTest(new MoneyTest("testSimpleAdd")); return suite; }

Testing practices Whenever you are tempted to type something into a print statement or a debugger expression, write it as a test instead You can always write more tests. However, you will quickly find that only a fraction of the tests you can imagine are actually useful During Development- When you need to add new functionality to the system, write the tests first During Debugging- When someone discovers a defect in your code, first write a test that will succeed if the code is working Once you get them running, make sure they stay running

Sacrifice design for testing If you ever feel tempted to make a private method public purely for testing purposes, don't do it. Testing is meant to improve the quality of your code, not decrease it

Statistical testing for non- deterministic code When the detailed results of a method are influenced by more than just the code in the method A chaotic example: testing the time it takes a message to travel from a Web server to a browser over the Internet Try to make some useful predictions about the expected values

Conclusion Unit tests are fairly easy to write and have very rapid performance, so it's not going to take you long to run them