1. 1 CMSC 132: Object-Oriented Programming II Nelson Padua-Perez William Pugh Department of Computer Science University of Maryland, College Park

2. 2 Overview Testing Unified Modeling Language (UML) Models & views Class diagrams Sequence diagrams

3. 3 Testing Goal Detect and eliminate errors in program Feedback to improve software Specification changes Add new functionality Extremely important for success!

4. 4 Testing Empirical testing Test software with selected test cases More scalable than verification Not guaranteed to detect all errors

5. 5 Testing – Terminology Test case Individual test Test suite Collection of test cases Test harness Program that executes a series of test cases Test framework Software that facilitates writing & running tests Example – JUnit

6. 6 Testing – Terminology Test driver Program to create environment for running tests Declares variables, creates objects, assigns values Executes code and displays results of tests Stub Skeleton code in place of unfinished method / class Simply return if called Possibly print message indicating stub called Allows software testing to begin

7. 7 Testing – Terminology Tester (Quality Assurance) Person devising and / or performing tests More effective if 2nd person writes tests Walkthrough Programmer explains code to 2 nd person

8. 8 Types of Testing Clear box testing Allowed to examine code Attempt to improve thoroughness of tests Black box testing No knowledge of code Treat program as “black box” Test behavior in response to inputs

9. 9 Levels (Stages) of Testing 1. Unit test 2. Integration test 3. System test 4. Acceptance test

10. 10 Unit Test Test individual units extensively Classes Methods Central part of “eXtreme Programming” (XP) Extensive unit testing during development Pair programming (1 coder, 1 tester) Design unit tests along with specification Approach Test each method of class Test every possible flow path through method

11. 11 Flow Path Unique execution sequence through program Example S1 while (B1) { if (B2) S2 else S3 } Flows S1 S1, S2 S1, S3 S1, S2, S2 S1, S2, S3 S1, S3, S2 S1, S3, S3 …

12. 12 Unit Test – Flow Path Not possible to test all flow paths Many paths by combining conditionals, switches Infinite number of paths for loops New paths caused by exceptions Test coverage Alternative to flow path Ensure high % (if not all) of lines of code tested Does not capture all possible flow paths Even if all lines of code tested by some test case

13. 13 Integration Test Test interaction between units Possible units fail when combined May find problems in specifications Approach Test units together Proceed bottom up, in increasing size Example test sequence 1. AB, AC, AD, CD, CE 2. ACD 3. ABCDE B A C D E

14. 14 System Test Test entire software Include all components of software In context in which software will be used Ensure all pieces of software interact correctly

15. 15 Acceptance Test Test full functionality of software Ensure program meets all requirements Approach Place software in user environment Test software with Real-world data Real users Typical operating conditions Test cases selected by users

16. 16 Acceptance Test – Stages Alpha test Test components during development Usually clear box test Beta test Test in real user environment Always black box test

17. 17 Regression Test Ensure functionality is not lost / changed As software is modified / extended Approach Save suite of tests and expected results Rerun test suite periodically after software changes Report any loss of functionality Typically run overnight Software is more stable when developers leave work

18. 18 Developing Test Cases Quality of testing depends on test cases Tips on developing test cases Develop test data during analysis & design phases Attempt to exercise alternate program paths Check boundary conditions 1 st and last iterations of loop 1 st and last values added to data structure Pay close attention to problem specification UML use cases  test cases

19. 19 UML UML (Unified Modeling Language) Graphic modeling language for describing object-oriented software Started in 1994 Combined notations from 3 leading OO methods OMT(James Rumbaugh) OOSE(Ivar Jacobson) Booch(Grady Booch) Industry standard Many features Large collection of notations Multiple views Multiple diagrams We focus mainly on Logical view of relationship between classes

20. 20 UML Motivation Software growing larger & complex Difficult to analyze Need to describe software design Clearly Concisely Correctly UML equivalent to software “blueprint” Provides simple yet clear abstraction for software Computer-aided software engineering (CASE) Tools for generating & analyzing UML

21. 21 (Some) UML Diagrams Class Describe static structure of the classes in system Sequence Describe dynamic behavior between users and objects Use case Describe functional behavior seen by (external) user State Describe dynamic behavior of objects as finite state machine Activity Model dynamic behavior of a system as a flowchart

22. 22 Sequence Diagram Object Message Activation Sequence diagrams represent behavior as interactions blinkHours() blinkMinutes() incrementMinutes() refresh() commitNewTime() stopBlinking() pressButton1() pressButton2() pressButtons1And2() pressButton1() :WatchUser :Time:LCDDisplay:SimpleWatch

23. 23 Use Case Diagrams WatchUserWatchRepairPerson ReadTime SetTime ChangeBattery Actor Use case Package SimpleWatch Use case diagrams represent functionality of system from external user’s point of view

24. 24 button1&2Pressed button1Pressed button2Pressed button1Pressed button1&2Pressed Increment Minutes Increment Hours Blink Hours Blink Seconds Blink Minutes Increment Seconds Stop Blinking State Diagrams State Initial state Final state Transition Event

25. 25 UML Class Diagrams Represent the (static) structure of the system During analysis Used to model problem domain concepts During detailed design Used to model classes

26. 26 Class Diagrams Class contains Name State Behavior Visibility Specifiers + public - private # protected ~ package

27. 27 UML Class Diagrams  Java Code Different representation of same information Name, state, behavior of class Relationship(s) between classes Should be able to derive one from the other Motivation UML  Java Implement code based on design written in UML Java  UML Create UML to document design of existing code

28. 28 Java  UML : Clock Example Java class Clock { // name // state private int seconds; private int minutes; private int hours; // behavior public void start(); public void adjustTime(int value); public void reset(); } Java Code Class Diagram