1. Writing a Unit test Using JUnit At the top of the file include: import junit.framework.TestCase; The main class of the file must be: public Must extend TestCase Methods of this class, in order to be run automatically when the Test command is invoked, must: Be public return void Take no arguments Have a name beginning with “test”

2. Writing a Unit test using JUnit Test methods in this class can call any of the following methods (among others): void assertTrue(String, boolean) void assertEquals(String, int, int) void fail(String) Issues an error report with the supplied String if the boolean is false Issues an error report with the supplied String if the two integers are not equal. The first int is the expected value, the second, the actual (tested) value. This method can be called with primitive or Objects (using their equals( ) method for comparison. This immediately causes the test to fail and issue an error report with the supplied String.

3. Writing Unit Tests using JUnit Example:Suppose we are writing a Calculator class that operates on pairs of numbers. Before writing the class, write some tests for it. Then write the Calculator class, compile it and the test class, and see if your Calculator code passes the tests you have set for it. If so, add more tests to check other cases that you discover in the process of writing and validating your code. Continue until you are satisfied that your code is correct and complete.

4. Example of using JUnit import junit.framework.TestCase; public class CalculatorTest extends TestCase { public void testAddition( ) { Calculator calc = new Calculator( ); // add 3 + 4 int expected = 7 int actual = calc.add(3, 4); assertEquals(“Adding 3 + 4 “, expected, actual); } public void testDivision( ) { Calculator calc = new Calculator( ); try { calc.divide(2, 0); fail(“Should have thrown an Exception”); } catch(ArithmeticException e) { System.out.printLine(“Good! Divide by aero exception caught”); } Test class extends TestCase Find actual result returned by Calculator method Use method assertEquals to compare expected and actual results

5. Running the Test Once the test code and the unit (class) to be tested have been written and compiled, you can run the test in DrJava by simply clicking on the Test button in the top Toolbar. JavadocTestResetCompile All InteractionsConsoleCompiler OutputTest Output Test Progress Show Stack Trace All tests completed successfully. Die DieTest testRoll (test code is located in this window)

6. Running the Test Alternatively, one can manually control the execution of the test program and select which of the test methods to select by including the following method: public static Test suite( ) { TestSuite suite = new TestSuite( ); suite.addTest(new (“ ”) ); ………………………………… return suite; } Must import Test and TestSuite from junit.framework package Additional information about using JUnit can be found in the JUnit Cookbook at http://junit.sourceforge.net/doc/cookbook/cookbook.htmhttp://junit.sourceforge.net/doc/cookbook/cookbook.htm

7. If the Test Fails A list of test failures is displayed in the Test Output tab in the bottom window similarly to compiler errors. To view a Stack Trace, right-click on the failure in the Test Output tab and select the Show Stack Trace button.

8. Test Driven Development (TDD) Always write the test before writing the code! The tests will actually get written – It is human nature to avoid writing unit tests after the code has been written. The programmer may rationalize that the code is correct and a time consuming test program is not needed. Programmer satisfaction – If the test is written first the programmer feels a need to write code to “pass the test” and gets a satisfaction out of doing so. Clarification of detailed interface and behavior – As you write the test code you must imagine that the code for the class you are testing actually exists. This makes you think through the details of the public view of the method. Provable, repeatable, automated verification – Over time the test base builds. The early investment in writing tests first pays dividends later as the size of the application grows. The confidence to change things – If a developer needs to change one of the existing classes, there are unit tests available that can be run to provide immediate feedback of whether the change produced an error.

9. Understanding Software’s Environment Application under test Operating System kernel UI File System API

10. Understanding Software’s Environment If an application makes a request of the OS – for example, to allocate memory – it must check that that request has been successfully completed, and assert the appropriate error condition if it has not. Disks can get full and networks congested. What happens to our software system when the expected resources are not available? Software must be tested under normal operating conditions, not in a vacuum. Normal operating conditions include situations in which the external environment becomes stressed.