Lecture 6

1. Lecture 6 OCL Use cases: managing requirements Testing Reusable Software Object-Based Software Object-Oriented Software Collaborations Testing

2. Testing Object-Based Software:chapter 21 • OO without inheritance and virtual functions • classes with data and function members • pre- and post-conditions for methods, class invariants (design by contract: book is not precise here!) Testing

3. Subsystem Size and Test Implementation • Class: smallest reasonable subsystem • testing methods in isolation: would require stubs • but we are looking for interaction errors • class too small a test unit Testing

4. Groups of classes • Often designed to work together • Test them together • Often have their own collective invariant Testing

5. Example • Three classes • Object_to_be_displayed, Visual_representation, Keyboard_controller • Invariant • any object to be displayed has at most one visual representation and the same number of keyboard controllers • Makes no sense to test in isolation Testing

6. Testing a group of methods of a class (section 21.2.2) • Will often still test group of classes since methods use other classes • Create pairs of sequences which are supposed to give same object • example: o1 and o2 should be the same • o1=s.parse(); t=o1.print(); o2=t.parse(); o1.equal(o2); • o1=s.parse(); o2=o1.copy(); o1.equal(o2); • tests printing, parsing,copying and equality function Testing

7. Class Requirement Catalog (21.3) • Integration requirements should be listed once and for all in a class requirement catalog for “important” classes Testing

8. Organization of class requirement catalog • Object use requirements • State machine requirements • Member function requirements Testing

9. Organization of class requirement catalog • Object use requirements • from class invariant: useful independent of member function called • State machine requirements • if class has state machine or statechart model • Member function requirements • preconditions, postconditions • Collaborations of objects Testing

10. Object-Oriented Software 1: Inheritance (chapter 22) • Inheritance structure of object-oriented software leads to inheritance structure in test design documents • Class A => Extended Class A1 • A test requirements => A1 test requirements • A test specifications => A1 test specifications Testing

11. What needs to be retested in subclasses? • Code which was tested in superclass, does it need to be retested in subclass? • Example: class Refrigerator { public: void set_desired_t(int t); int get_t(); void calibrate(); private int t;} Testing

12. What needs to be retested in subclasses? • set_desired_t allows the temperature to be between 5 and 20 degrees C. calibrate() puts the actual refrigerator through several cooling cycles and uses sensor readings to calibrate the cooling unit class Refrigerator { public: void set_desired_t(int t); int get_t(); void calibrate(); private int t;} Testing

13. What needs to be retested in subclasses? • A new more capable refrigerator: set_desired_t allows the temperature to be between -5 and 20 degrees C. calibrate() is unchanged: do we have to retest calibrate? YES! class Refrigerator { public: void set_desired_t(int t); int get_t(); void calibrate(); private int t;} Testing

14. What needs to be retested in subclasses? • Assume that calibrate works by dividing sensor reading by temperature.In the improved refrigerator we might get a division by zero error which could not have happened in the original code. HAVE TO RETEST ALSO INHERITED, UNCHANGED CODE. Testing

15. Test requirement checklist for subclass • B inherits from A class A { public: virtual void member1(); virtual void member2(); protected: Count count1; Count count2;} class B : public A { public: void member1(); void member3() protected: Count count3;} Testing

16. Test requirement checklist for subclass • To test B, create three test requirement checklists, one for each member function. • Member1 and member3 are new code. Their checklist must be complete • Member 2 is unchanged: contains requirements that tests interactions with member1 and member3 Testing

17. What is gained? • New checklist for B contains only requirements for new code and inherited code affected by the change: might require much less work than testing B from scratch Testing

18. Reuse tests for superclass • If A was tested in isolation, rerun A’s tests against B. Why useful? • Tests for A may satisfy some of the new test requirements: saving test specifications • Can be a cheap way to exercise B thoroughly Testing

19. Design for Testability • Implementation of concrete class must obey constraints described by its abstract superclass. • Constraint checks • self-check functions • Trace checks • check effects of a sequence of operations Testing

20. Constraint check • Example: For each class, a method g_check(). Checks integrity of object. Minimal g_check can be generated automatically from UML class diagram: • Are all cardinality constraints satisfied? • Are all required parts non-null? • Self-check functions are also very useful during debugging: Demeter/C++ Testing

21. Trace checks • Check effect of sequences of operations • Constant traces • o.f().g().h() does not change o • Equivalent traces • o.f().g().h() = o.a().b().c() • Simulation traces • design simulated objects (ATM customer) • generate tests from use cases • use random generation Testing

22. Genericity • Template class catalog captures what is common to all instantiations • Individual instantiations will create instantiated class catalogs which usually differ in only small ways. • Test requirements for template class’s member functions can be written at template level. Maybe incomplete. Testing

23. Genericity • But are usually nearly complete. Testing

24. Testing collaborations • Problem: tangled with other code • White-box testing needs to recover the collaborations from the tangled code • Identify roles played by the classes • Same abstract collaboration may be present several times. Develop tests for abstract collaboration and adapt them Testing

25. Testing collaborations • Testing as an opportunity to improve the design • How to describe the improved design which is used to develop the test requirements and the test specifications • This is a common theme: have to develop a model of the software under test Testing

26. Testing collaborations • Finding the abstract collaborations • Identify participants • important • they do real work • unimportant • they are only used as transmitters of control and information Testing

27. Modeling collaborations • Write down group of collaborating classes • Separate code for pure navigation through classes from code which does interesting work • Write test requirements for navigation • does code go to right objects in correct order? • Write test requirements for interesting code Testing

28. Modeling collaborations • Do similar collaborations occur for similar sets of collaborating classes? They may have completely different names and different detailed connections but the connectivity relationships at a suitable level of abstraction are identical • Study paper on modeling collaborations Testing

29. Testing

30. Resource Allocation reqs <JobCategory> <Facility> 0..* type provides 0..* <Job> when: TimeInterval schedule allocated <Resource> 0..* 0..1 inv Job::allocated<>0 ==> allocated.provides->includesAll(type.reqs) --Any allocated resource must have the required facilities inv Resource::jo1, jo2: Job:: (schedule->includesAll({jo1,jo2}) ==> jo1.when.noOverlap(jo2.when) -- no double-booking of resources Testing

31. Resource Allocation reqs JobDescription Skill 0..* type JobCategory Facility provides 0..* Resource Allocation Resource Job Job when: TimeInterval schedule allocated Plumber 0..* 0..1 Customer Application of resource allocation to Pluming Testing