In-Class Extended Example Ch. 6.4

Slides:



Advertisements
Similar presentations
Introduction to Software Testing Chapter 6-4 Input Space Partition Testing Paul Ammann & Jeff Offutt
Advertisements

Software Testing Logic Coverage. Introduction to Software Testing (Ch 3) © Ammann & Offutt 2 Logic Coverage Four Structures for Modeling Software Graphs.
Introduction to Software Testing Chapter 3.1, 3.2 Logic Coverage Paul Ammann & Jeff Offutt
Logic ChAPTER 3 1. Truth Tables and Validity of Arguments
Data Abstraction II SWE 619 Software Construction Last Modified, Spring 2009 Paul Ammann.
Bag implementation Add(T item) – Enlarge bag if necessary; allocate larger array Remove(T item) – Reduce bag if necessary; allocate smaller array Iterator.
CSE 143 Lecture 22: Advanced List Implementation (ADTs; interfaces; abstract classes; inner classes; generics; iterators)
Boolean Algebra Computer Science AND (today is Monday) AND (it is raining) (today is Monday) AND (it is not raining) (today is Friday) AND (it is.
Iterators Chapter 7. Chapter Contents What is an Iterator? A Basic Iterator Visits every item in a collection Knows if it has visited all items Doesn’t.
1 Topic 8 Iterators "First things first, but not necessarily in that order " -Dr. Who.
Introduction to Software Testing Chapter 3.1 Logic Coverage Paul Ammann & Jeff Offutt.
Introduction to Software Testing Chapter 8.2
Phil 120 week 1 About this course. Introducing the language SL. Basic syntax. Semantic definitions of the connectives in terms of their truth conditions.
CS 307 Fundamentals of Computer ScienceIterators 1 Topic 14 Iterators "First things first, but not necessarily in that order " -Dr. Who.
CSE 143 Lecture 15 Sets and Maps; Iterators reading: ; 13.2; 15.3; 16.5 slides adapted from Marty Stepp
3.2 – Truth Tables and Equivalent Statements
Logic ChAPTER 3.
Today’s Agenda  Quick Review  Finish Graph-Based Testing  Predicate Testing Software Testing and Maintenance 1.
Introduction to Software Testing Chapter 8.1 Logic Coverage Paul Ammann & Jeff Offutt
EECE 310: Software Engineering Iteration Abstraction.
CSE 143 Lecture 4 ArrayList Reading: 10.1 slides created by Marty Stepp
1 Iterators "First things first, but not necessarily in that order " -Dr. Who CS Computer Science II.
Introduction to Software Testing Chapter 3.6 Disjunctive Normal Form Criteria Paul Ammann & Jeff Offutt
Boolean Logic. Boolean Operators (T/F) xyx AND y FFF FTF TFF TTT xyx OR y FFF FTT TFT TTT xNOT x FT TF.
Introduction to Software Testing Chapter 3.1, 3.2 Logic Coverage Paul Ammann & Jeff Offutt
© 2005 Pearson Education, Inc., Upper Saddle River, NJ. All rights reserved. Data Structures for Java William H. Ford William R. Topp Chapter 13 Implementing.
Warmup Answer the following True/False questions in your head: I have brown hair AND I am wearing glasses I am male OR I am wearing sneakers I am NOT male.
(c) University of Washington16-1 CSC 143 Java Linked Lists Reading: Ch. 20.
Boolean Logic.
Introduction to Software Testing Chapter 3.6 Disjunctive Normal Form Criteria Paul Ammann & Jeff Offutt
Introduction to Software Testing Chapter 3.6 Disjunctive Normal Form Criteria Paul Ammann & Jeff Offutt
Introduction to Software Testing Chapter 3.1 Logic Coverage Paul Ammann & Jeff Offutt.
Iteration Abstraction SWE Software Construction Fall 2009.
CS61B L13 Lists (1)Garcia / Yelick Fall 2003 © UCB  Dan Garcia ( Kathy Yelick  (
CSE 143 Lecture 12: Sets and Maps reading:
Introduction to Software Testing Chapter 3.4 Logic Coverage for Specifications Paul Ammann & Jeff Offutt
Iterators. Iterator  An iterator is any object that allows one to step through each element in a list (or, more generally, some collection).
Introduction to Software Testing Chapter 8.2
EKT472: Object Oriented Programming
CSE 143 Lecture 14 Interfaces; Abstract Data Types (ADTs)
Paul Ammann & Jeff Offutt
Introduction to Software Testing Chapter 8.1 Logic Coverage
EECE 310: Software Engineering
CSE 373 Implementing a Stack/Queue as a Linked List
ISP Coverage Criteria CS 4501 / 6501 Software Testing
Introduction to Software Testing Syntactic Logic Coverage Criteria
Fundamentals of Java: AP Computer Science Essentials, 4th Edition
Input Space Partition Testing CS 4501 / 6501 Software Testing
Boolean logic Taken from notes by Dr. Neil Moore
Iteration Abstraction
Paul Ammann & Jeff Offutt
Paul Ammann & Jeff Offutt
"First things first, but not necessarily in that order " -Dr. Who
Introduction to Software Testing Chapter 3 Test Automation
CSE 143 Lecture 27: Advanced List Implementation
Lecture 26: Advanced List Implementation
slides adapted from Marty Stepp
Abstract Class As per dictionary, abstraction is the quality of dealing with ideas rather than events. For example, when you consider the case of ,
"First things first, but not necessarily in that order." -Dr. Who
Iteration Abstraction
SWE 619 Software Construction Last Modified, Fall 2015 Paul Ammann
ISP Coverage Criteria CS 4501 / 6501 Software Testing
Interator and Iterable
"First things first, but not necessarily in that order " -Dr. Who
Boolean logic Taken from notes by Dr. Neil Moore
Introduction to Software Testing Chapter 8.1 Logic Coverage
"First things first, but not necessarily in that order " -Dr. Who
Iterators Dan Fleck.
TCSS 143, Autumn 2004 Lecture Notes
CSE 143 Lecture 21 Advanced List Implementation
Presentation transcript:

In-Class Extended Example Ch. 6.4 Form teams of two to three neighbors Hand out printouts of Iterator.html http://docs.oracle.com/javase/7/docs/api/java/util/Iterator.html Close books We will go through the steps for designing an IDM for Iterator After each step, we will stop & discuss as a class I use these slides to step through the example in section 6.4. At each step, I pause and let students work together to complete the step. Then I show them the solution from the book. This is slower than just showing the example, but the students learn a lot more through this “active learning exercise.” I find it easier if I print the slides on paper (2X3 and front and back) so I can keep on track with the example. 12-Nov-18 © Ammann & Offutt

Task I: Determine Characteristics Step 1: Identify: Functional units Parameters Return types and return values Exceptional behavior work … 12-Nov-18 © Ammann & Offutt

Task I: Determine Characteristics Step 1: Identify: hasNext() – Returns true if more elements E next() – Returns next element Exception: NoSuchElementException void remove() – Removes the most recent element returned by the iterator Exception: Unsupported-OperationException Exception: IllegalStateException parameters: state of the iterator iterator state changes with next(), and remove() calls modifying underlying collection also changes iterator state 12-Nov-18 © Ammann & Offutt

Task I: Determine Characteristics Step 2: Develop Characteristics Table A: Method Params Returns Values Exception Ch ID Character-istic Covered by hasNext state boolean true, false next E element generic E, null remove work … 12-Nov-18 © Ammann & Offutt

Task I: Determine Characteristics Step 2: Develop Characteristics Table A: Method Params Returns Values Exception Ch ID Character-istic Covered by hasNext state boolean true, false C1 More values next E element generic E, null remove 12-Nov-18 © Ammann & Offutt

Task I: Determine Characteristics Step 2: Develop Characteristics Table A: Method Params Returns Values Exception Ch ID Character-istic Covered by hasNext state boolean true, false C1 More values next E element generic E, null C2 Returns non-null object remove 12-Nov-18 © Ammann & Offutt

Task I: Determine Characteristics Step 2: Develop Characteristics Table A: Method Params Returns Values Exception Ch ID Character-istic Covered by hasNext state boolean true, false C1 More values next E element generic E, null C2 Returns non-null object NoSuchElement remove 12-Nov-18 © Ammann & Offutt

Task I: Determine Characteristics Step 2: Develop Characteristics Table A: Method Params Returns Values Exception Ch ID Character-istic Covered by hasNext state boolean true, false C1 More values next E element generic E, null C2 Returns non-null object NoSuchElement remove Unsupported C3 remove() supported 12-Nov-18 © Ammann & Offutt

Task I: Determine Characteristics Step 2: Develop Characteristics Table A: Method Params Returns Values Exception Ch ID Character-istic Covered by hasNext state boolean true, false C1 More values next E element generic E, null C2 Returns non-null object NoSuchElement remove Unsupported C3 remove() supported IllegalState C4 remove() constraint satisfied Note the “or” in this part of the specification for remove(): IllegalStateException - if the next method has not yet been called, or the remove method has already been called after the last call to the next method Done! 12-Nov-18 © Ammann & Offutt

Task I: Determine Characteristics Step 4: Design a partitioning Which methods is each characteristic relevant for? How can we partition each characteristic? Table B: ID Characteristic hasNext() next() remove() Partition C1 More values C2 Returns non-null object C3 remove() supported C4 remove() constraint satisfied work … 12-Nov-18 © Ammann & Offutt

Task I: Determine Characteristics Step 4: Design a partitioning Relevant characteristics for each method Table B: ID Characteristic hasNext() next() remove() Partition C1 More values X C2 Returns non-null object C3 remove() supported C4 remove() constraint satisfied Students often ask why C1 and C2 apply to remove(). Whether the structure has more values should NOT affect remove() (C1), but the method COULD have a fault where it behaves badly if the current element is last in the structure. Likewise, remove() could have a fault that only manifests if the current element is a null pointer (C2). So considering C1 and C2 leads to some subtle tests that could reveal faults. 12-Nov-18 © Ammann & Offutt

Task I: Determine Characteristics Step 4: Design a partitioning Table B: ID Characteristic hasNext() next() remove() Partition C1 More values X {true, false} C2 Returns non-null object C3 remove() supported C4 remove() constraint satisfied Done with task I! 12-Nov-18 © Ammann & Offutt

Task II: Define Test Requirements Step 1: Choose coverage criterion Step 2: Choose base cases if needed work … 12-Nov-18 © Ammann & Offutt

Task II: Define Test Requirements Step 1: Base coverage criterion (BCC) Step 2: Happy path (all true) Step 3: Test requirements … 12-Nov-18 © Ammann & Offutt

Task II: Define Test Requirements Step 3: Test requirements Table C: Method Characteristics Test Requirements Infeasible TRs hasNext C1 next C1 C2 remove C1 C2 C3 C4 work … 12-Nov-18 © Ammann & Offutt

Task II: Define Test Requirements Step 3: Test requirements Table C: Method Characteristics Test Requirements Infeasible TRs hasNext C1 {T, F} next C1 C2 {TT, FT, TF} remove C1 C2 C3 C4 {TTTT, FTTT, TFTT, TTFT, TTTF} 12-Nov-18 © Ammann & Offutt

Task II: Define Test Requirements Step 4: Infeasible test requirements Table C: C1=F: has no values C2=T: returns non-null object Method Characteristics Test Requirements Infeasible TRs hasNext C1 {T, F} none next C1 C2 {TT, FT, TF} FT remove C1 C2 C3 C4 {TTTT, FTTT, TFTT, TTFT, TTTF} FTTT 12-Nov-18 © Ammann & Offutt

Task II: Define Test Requirements Step 5: Revised infeasible test requirements Table C: Method Characteristics Test Requirements Infeasible TRs Revised TRs # TRs hasNext C1 {T, F} none n/a 2 next C1 C2 {TT, FT, TF} FT FT  FF 3 remove C1 C2 C3 C4 {TTTT, FTTT, TFTT, TTFT, TTTF} FTTT FTTT  FFTT 5 Done with task II! 12-Nov-18 © Ammann & Offutt

Task III: Automate Tests First, we need an implementation of Iterator (Iterator is just an interface) ArrayList implements Iterator Test fixture has two variables: List of strings Iterator for strings setUp() Creates a list with two strings Initializes an iterator 12-Nov-18 © Ammann & Offutt

Task III: Automate Tests remove() adds another complication … “The behavior of an iterator is unspecified if the underlying collection is modified while the iteration is in progress in any way other than by calling this method.” Subsequent behavior of the iterator is undefined! This is a constraint on the caller: i.e. a precondition Preconditions are usually bad: Legitimate callers often make the call anyway and then depend on whatever the implementation happens to do Malicious callers deliberately exploit “bonus behavior” 12-Nov-18 © Ammann & Offutt

Task III: Automate Tests A merely competent tester would not test preconditions All specified behaviors have been tested! A good tester … … with a mental discipline of quality … would ask … What happens if a test violates the precondition? 12-Nov-18 © Ammann & Offutt

Tests That Violate Preconditions Finding inputs that violate a precondition is easy But what assertion do you write in the JUnit test? List<String> list = … // [cat, dog] Iterator<String> itr = list.iterator(); itr.next(); // can assert! return value is “cat” list.add(“elephant”); // just killed the iterator itr.next(); // cannot assert! Note: In the Java collection classes, the Iterator precondition has been replaced with defined behavior ConcurrentModificationException That means we can write tests in this context 12-Nov-18 © Ammann & Offutt

Task I: Determine Characteristics Cycle back to add another exception—Table A revised: Method Params Returns Values Exception Ch ID Character-istic Covered by work … 12-Nov-18 © Ammann & Offutt

Task I: Determine Characteristics Cycle back to add another exception—Table A revised: Method Params Returns Values Exception Ch ID Character-istic Covered by hasNext state boolean true, false C1 More values ConcurrentModification C5 next E element generic E, null C2 Returns non-null NoSuchElement remove Unsupported C3 remove() supported IllegalState C4 remove() constraint satisfied Collection not modified 12-Nov-18 © Ammann & Offutt

Task II: Define Test Requirements Cycle back to Step 5: Revised infeasible test requirements Table C revised: Method Characteristics Test Requirements Infeasible TRs Revised TRs # TRs work … 12-Nov-18 © Ammann & Offutt

Task II: Define Test Requirements Cycle back to Step 5: Revised infeasible test requirements Table C revised: Method Characteristics Test Requirements Infeasible TRs Revised TRs # TRs hasNext C1 C5 {TT, FT, TF} none n/a 3 next C1 C2 C5 {TTT, FTT, TFT, TTF} FTT TTF FTT  FFT TTF  TFF 4 remove C1 C2 C3 C4 C5 {TTTTT, FTTTT, TFTTT, TTFTT, TTTFT, TTTTF} FTTTT FTTTT  FFTTT 6 12-Nov-18 © Ammann & Offutt

Task III: Automate Tests All tests are on the book website: http://cs.gmu.edu/~offutt/softwaretest/java/IteratorTest.java 12-Nov-18 © Ammann & Offutt