1. ECOM 6330 Java Parallel and Distributed computing
9/13/2011
ECOM Java Parallel and Distributed computing
Lecture 02
______________________
Hatem M. Hamad
Computer Engineering Department
Islamic University of Gaza
_____________________________________________________________
Lec 01

2. The Agile:
What Drives Traditional Software Engineering, and Why Agile Turns it
Upside Down

3. Overview Traditional Evolutionary Design circa 1970 Planned Design
A Disaster!
Planned Design
Managing The Cost Curve Through Upfront Analysis
The Heart of Modern Software Design
Agile Approaches
The Return Of Evolution
Managing The Cost Curve Through
Testing
Post Development Design
4/4/2019

4. Traditional Evolutionary Design
Successful In Other Engineering Disciplines
Each Successive Widget Is an Improvement
In the Beginning, Programmers Just Programmed
Result Was Ad Hoc Structure
Eventually Hard – Impossible, Actually - To Maintain
The tendency towards irreducible number of errors
In a suitably complex system, any attempt to fix observed errors tends to result in the introduction of other errors
Key is managing complexity
4/4/2019

5. Planned Design Introduction of Traditional Development Phases
Requirements, System Design, Detailed Design, etc.
Heavy Reliance on Upfront Analysis
The big errors are made at the beginning and rarely recognized. If caught at all, it is usually after fielding. The lesser errors surface as soon as coding begins and shout out when the first real user tests a prototype
Early Life Cycle Effort
Expect Change, and Plan for it
Identify Defects Early
4/4/2019

6. Traditional Cost of Change Curve
4/4/2019

7. Agile: The Return of Evolution
The Problem With Traditional Design:
The Track Record of Anticipating Change is Pretty dirty
Extremely Difficult To Maintain Non Executable Documents
How Relevant Is Your UML After Six Months?
What Does It Mean If Your Design Needs To Change?
Failure In Prior Design Process? (Traditional) vs
Normal First Class Problem In Software Design? (Agile)
How Often Are You Running Your Tests?
Key Gap: Divergence Between Different Development Teams
4/4/2019

8. Defect Discovery: Agile vs. Traditional
4/4/2019

9. A Different Approach To Managing The Cost Curve
The Test Harness As Guardian
(Near) Instant Feedback on Changes (or Mistakes)
An Hour? Ten Minutes? Less?
Implies Something Is Executable From The Very Beginning
The Role of Continuous Integration
Effective Communication Mechanism
De-Emphasize Non Executable Artifacts
If It Doesn’t Execute, It’s Not Checkable
4/4/2019

10. Agile Cost of Change Curve
4/4/2019

11. Refactoring – The New Design
Design Still Matters
Agile Distributes Design Effort
Focus is on Needed, Rather Than Anticipated, Functionality
Refactoring Requires Recognizing Defective Designs
And Replacing Them with Functionally Equivalent Designs
Requires Basic Training in Code Smells
Maintenance vs. Green Fields Development
After First 15 Minutes
All Projects Are Maintenance Projects
4/4/2019

12. Testing
A program or part of a program under controlled conditions to verify that results are as expected
Detects program defects after the program compiles.
Cannot detect all possible defects in complex programs
Testing is an art and science

13. Testing Levels Unit testing: tests the smallest testable piece
Integration testing: tests integration among units
System testing: tests the whole program
Acceptance testing: system testing to show program meets functional requirements

14. Types of Testing Black-box testing:
tests the item based on its interfaces and functional requirements
is also called closed-box or functional testing
Is accomplished by
varying input parameters
comparing with independently calculated results

15. Types of Testing (cont.)
White-box testing:
tests the item with knowledge of its internal structure
is also called glass-box, open-box, or coverage testing
exercises as many paths through the element as possible
provides appropriate coverage
statement – ensures each statement is executed at least once
branch – ensures each choice of branch (if , switch, loops) is taken
path – tests each path through a method

16. Preparations for Testing
Early in the design stage!!
Easier to find
Less expensive it is to correct it
Test plans include deciding:
how the software will be tested
when the tests will occur
who will do the testing
what test data will be used
Error cost increases exponentially as it gets out for production

17. Testing Tips for Program Systems
DOCUMENTATION! (use javadoc)
Trace of execution: display the method name as you enter it
Display
All input parameters upon entering a method
Values of any class attributes accessed by the method
All method outputs after returning from a method
Class attributes that are modified by a method

18. Testing Tips for Program Systems (cont.)
An efficient way to display values of parameters, return values, and class attributes:
private static final boolean TESTING = true; // or false to // disable
if (TESTING) {
// Code for output statements }

19. Developing the Test Data
In black-box testing, check for
all expected inputs
unanticipated data
In white-box testing
ensure all combinations of paths through the code are executed

20. Testing Boundary Conditions
Example
for (int i = 0; i < x.length; i++) {
if (x[i] == target)
return i; }
Test the boundary conditions (for white-box and black-box testing) when target is:
first element (x[0] == target is true)
last element (x[length-1] == target is true)
not in array (x[i] == target is always false)
present multiple times (x[i] == target for more than one value of i)

21. Testing Boundary Conditions (cont.)
for (int i = 0; i < x.length; i++) {
if (x[i] == target)
return i; }
Test for the typical situation when target is:
somewhere in the middle
and for the boundary conditions when the array has
only one element
no elements

22. Stubs
Stubs are method placeholders for methods called by other classes, but not yet implemented
A sample stub:
public void save() {
System.out.println("Stub for save has been called");
modified = false; }

23. Preconditions and Postconditions
Precondition: statement of any assumptions or constraints on the input parameters before a method begins execution
Postcondition: result of executing the method, including any change to the object’s state
/** Method Save
pre: the initial directory contents are read from a data file
post: writes the directory contents back to a data file */
public void save() {
. . . }
A method's preconditions and postconditions serve as a contract between a method caller and the method programmer

24. Drivers Another testing tool A driver program
declares any necessary object instances and variables
assigns values to any of the method's inputs (specified by the preconditions)
calls the method
displays the outputs returned by the method

25. A Different Approach To Software Development
The Challenge: Solving the Right Problem Right
Solution: Being Test-Driven
Build it Right: TDD
Building the Right Thing: Acceptance TDD
Tools for Test-Driven Development
4/4/2019

26. The Challenge: Solving the Right Problem Right
Most Systems Don’t Work “Quite Right”
Creating Poorly Written Code
Lots of Drivers: Time to Market, New Technologies, Lots of Code
Nightmare to Maintain
“I don’t want to touch that!”
Failing to Meet Actual Needs
Do Specifications Actually Capture Customer Requirements?
4/4/2019

27. (One) Solution: Being Test-Driven
Approaches
Traditional: Design, Implement, Maybe Test
TDD: Test, Implement, Refactor
High Quality with TDD
Quality Comes in Many Flavors
Less Time Fixing Defects
“Aged” Defects are Much More Expensive to Fix
Meeting Needs with Acceptance TDD
Formulating Requirements Directly As Acceptance Tests
What’s In It for Me?
No More Long Debugs, More Confident, More Time
4/4/2019

28. Evolutionary Design Traditional Design Advice is to Anticipate Design
Designers Often Anticipate Changes That Don’t Happen
Anticipated
Change
Anticipated
Change That
Doesn’t Happen
Emerging
Design
Unanticipated
Change
Both Anticipated and Unanticipated Change Affects Design
4/4/2019

29. Build It Right: TDD Test-Code-Refactor: The HeartBeat
The Rule: Only Ever Write Code To Fix A Failing Test
Traditional Development Cycle
Test-Driven Development Cycle
TDD Vocabulary
Test
Code
Design
Design
Code
Test
Refactor
Code
Test
Sometimes Called Red-Green-Refactor
4/4/2019

30. Build It Right: TDD First, We Write A Test
This Really Amounts To Design By Example
We Make API decisions
We’re Thinking Hard About How Code Is Used
We’re Taking a Client Perspective
That’s Good!
We’re Working At A Very Small Scale
Example for a Stack
stack = …; stack.push(x); y = stack.pop(); assertEquals(x,y);
Note: A Simple Setter/Getter Approach Satisfies This Test.
Start With One Concrete Client Interaction
4/4/2019

31. Build It Right: TDD Then We Write Just Enough Code
We Don’t Write More Code
All We Want Is To Make The Test Pass
It Should Be A Very Small Gap
Implementation Probably Not Optimal
We Don’t Care (Yet)
Goal: Make Code Base (Just) Pass Test Suite
4/4/2019

32. Build It Right: TDD And Then We Refactor
TDD Without Refactoring Just Makes Ugly Code
Thoroughly Tested, But Ugly
There Are A Variety of Transforms To Address This
Developing In Small Increments
The Code Always Runs!
Changes Are Small Enough To Fit In Our Heads
TimeFrame is Minutes To (Maybe) Hours
Evolutionary Design
Anticipated Vs Unanticipated Changes
Many “Anticipated Changes” Turn Out To Be Unnecessary
4/4/2019

33. Build It Right: TDD Keeping Code Healthy With Refactoring
Refactoring is Disciplined
Wait For A Problem Before Solving It
Refactorings are Transformations
Many Refactorings Are Simply Applications of Patterns
Refactorings Alter Internal Structure
Refactorings Preserve Behavior
Refactoring: A disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior
Focus Is On Current Code, Not Future Code
4/4/2019

34. Build It Right: TDD Making Sure The Software Still Works
Protection With Automated Tests
Test Harness is Only Thing That Ensures Software Works
Rerun Tests After Each Change (Regression Testing)
Fast Feedback
Sometimes, Entire Test Suite Is Too Slow
Role Of Continuous Integration Servers
Regression Tests In Background
Management of Multiple Developers/Multiple Changes
TDD Works In Actual Practice
4/4/2019

35. Build The Right Thing: “Acceptance” TDD
TDD For Requirements Capture
Closely Related To Use Cases
Tests Are The Shared Language
Clients and Developers Agree On Concrete Stories
Tests as Specifications
Most People Understand Examples Better Than Definitions
Specification By Example
A Powerful Way To Convey
The Exceptions and Variations
4/4/2019

36. Tools for Test-Driven Development
Unit Testing With JUnit
Without Tools, TDD Is Infeasible
4/4/2019

37. JUnit
JUnit, a popular program for Java projects, helps you develop testing programs
JUnit is an open source Java testing framework used in TDD. JUnit was originally written by Erich Gamma and Kent Beck. It is an instance of the xUnit architecture for unit testing frameworks.

38. Program testing Testing is a science A test framework facilitates:
Writing test cases
Organizing Test suites
Running test suites

39. Debugger Helps stop our program Look into variable values Why use it?
Understand other people’s code
Understand OOP
CS340

40. Design of JUnit
JUnit is designed around two key design patterns: the Command pattern and the Composite pattern.
A TestCase is a Command object. It can define any number of public testXXX() methods and any test class that has test methods should extend the TestCase class.

41. Desgin of JUnit (2)
The test class can use the setUp() and tearDown() methods to initialize and release common objects under test, referred to as the test fixture.
TestCase instances can be composed into TestSuites that can automatically invoke all the testXXX() in each TestCase instance. TestSuite can also have other TestSuite instances and this allows the test to run automatically and provide test status.

42. How to install JUnit?
First, download the latest version of JUnit from (Note: Eclipse should already have JUnit installed.)
For installing JUnit on Windows:
Unzip the junit.zip to %JUNIT_HOME%
Add JUnit to classpath:
set CLASSPATH=%JUNIT_HOME%\junit.jar

43. How to write JUnit Test Case?
To write a test case follows these steps:
Define a subclass of TestCase.
Overide the setUp() method to initialize objects under test.
Optionally overide tearDown() method to release object under test.
Define one or more public testXXX() methods that exercise the objects under test.

44. Sample Test Case import junit.framework.TestCase;
public class ShoppingCartTest extends TestCase {
private ShoppingCart cart;
private Product book1;
// Sets up the test fixture.
//Called before every testcase method.
protected void setUp() {
cart = new ShoppingCart();

45. Sample Test Case (2) //Tests emptying the cart.
book1 = new Product("Pragmatic Unit Testing", 29.95);
cart.addItem(book1); }
//Tears down the test fixture.
//Called after every test case method.
protected void tearDown() {
// release objects under test here
//Tests emptying the cart.

46. Sample Test Case (3) public void testEmpty() { cart.empty();
assertEquals(0, cart.getItemCount()); }
... };

47. How to write JUnit Test Suite?
A TestSuite comprises of various TestCase instances.
To write a test suite follow these steps:
Create a class that defines a static suite() factory method which creates TestSuites for all tests.
Optionally define a main() method that runs the TestSuite in batch mode.

48. Sample Test Suite import junit.framework.Test;
import junit.framework.TestSuite;
public class EcommerceTestSuite {
public static Test suite() {
TestSuite suite = new TestSuite();
// The ShoppingCartTest we created above.
suite.addTestSuite(ShoppingCartTest.class)

49. Sample Test Suite (2) // Another example test suite of tests.
suite.addTest(CreditCardTestSuite.suite());
// Add more tests here
return suite; }
//Runs the test suite using the textual runner.
public static void main(String[] args) {
junit.textui.TestRunner.run(suite());

50. How to Run JUnit tests?
JUnit provides textual and graphical interface (GI) to run tests. Both interface indicates how many tests were run, errors or failures and test status, “OK” for textual and green bar in GI.
For running tests from textual interface: java junit.textui.TestRunner ShoppingCartTest
For running tests from graphical interface: java junit.swingui.TestRunner ShoppingCartTest

51. Assertions for JUnit JUnit uses assertion methods to test conditions:
assertEquals(a,b) – a and b must be primitives or have an equals method for comparison
assertFalse(a) - a must be boolean
assertNotNull(a) - a is either object or null
assertNotSame(a,b) – test for object equality
assertNull(a) - a is either object or null
assertSame(a,b) – test for object equality
assertTrue(a) - a must be boolean

52. Why use JUnit? Its free! It is simple and elegant to use.
It is easy and inexpensive to write tests using the JUnit testing framework.
JUnit tests checks their own result and provide quick visual feedback.
Tests can be composed into TestSuites.
It is integrated into IDE’s like Eclipse and NetBeans.

53. References “Junit”
Clark, Michael. “JUnit Primer” October 7, [ (April 18, 2004)
“testdriven.com: Yours test-driven development community – News” [ (April 18, 2004)
“JUnit, Testing Resources for Extreme Programming” [ (April 18, 2004)