Testing Object-Oriented Software. COMP 4004 Fall Notes Adapted from Dr. A. Williams

Transcription

1 Testing Object-Oriented Software COMP 4004 Fall 2008 Notes Adapted from Dr. A. Williams Dr. A. Williams, Fall 2008 Software Quality Assurance Lec 9 1 Testing Object-Oriented Software Relevant characteristics for testing: Encapsulation: access restrictions on variables, methods, classes. Inheritance: code for an object may be in multiple classes in a hierarchy. Polymorphism / dynamic binding: exact version of a method called, or other behaviour, is not known until runtime. Abstract classes: cannot be instantiated and tested directly. Constructors and destructors: creation and termination of objects. Generic classes: Parameterized classes. Dr. A. Williams, Fall 2008 Software Quality Assurance Lec 9 2

2 Additional common OO properties Exceptions Increased number of potential execution paths. How to cause them for testing? State dependent behaviour: Functionality of methods depends on the order methods are called and the data with which they are provided. With encapsulation, state dependencies may not be visible externally. Dr. A. Williams, Fall 2008 Software Quality Assurance Lec 9 3 Encapsulation Restricted class members How to test these methods (for example, using JUnit)? Class TestMe private int somefunction( int someparameter ); protected int tryme( int data ); public int publicmethod( int mydata ); Dr. A. Williams, Fall 2008 Software Quality Assurance Lec 9 4

3 What about...? Encapsulation Inner classes public Class X private Class TestMe // fields and methods for TestMe // fields and methods for X Dr. A. Williams, Fall 2008 Software Quality Assurance Lec 9 5 Potential strategies Restricted access to methods: Access methods indirectly: find an access point that is public, that should result in a call to the desired method. Derive a call graph for the class methods, and access the restricted methods indirectly from the nearest public method in the call graph. For languages using a virtual machine (VM): Custom VM that allows JUnit access Access via VM / debugger tools interface Example: JVMTI: Java Virtual Machine Tools Interface. Dr. A. Williams, Fall 2008 Software Quality Assurance Lec 9 6

4 Potential strategies Restricted access to data: Auto-increment values for new objects It may not be possible to predict values in advance, but if two consecutive objects are created, they should have consecutive autoincrement values. Dr. A. Williams, Fall 2008 Software Quality Assurance Lec 9 7 Inheritance Factors: Adding new methods Overriding methods from superclass. may call super() Use of protected fields and methods. Constructors: not inherited may call super() Dr. A. Williams, Fall 2008 Software Quality Assurance Lec 9 8

5 Inherited and Overridden Methods There are three possibilities for testing methods from the superclass. 1. No retesting of a method in the superclass is needed for the subclass. 2. Test cases that were run for the superclass can be run for the subclass to check the methods in the new context. 3. New test cases are needed for the subclass. Dr. A. Williams, Fall 2008 Software Quality Assurance Lec 9 9 Inherited methods Do the extensions to the class interact with the superclass or simply add additional attributes? If the subclass is purely an extension, retesting of the methods inherited from the superclass, using a subclass object, may not be needed. If the extensions affect the object s state, especially from the superclass point of view, then retesting of the superclass should be done, using an object from the subclass. Dr. A. Williams, Fall 2008 Software Quality Assurance Lec 9 10

6 Overriding methods Is the superclass version of the method called as well? If the superclass version of the method is called, try the test cases from the superclass in the new context. For additional functionality, new tests can be added specifically for the subclass. If not: Functionality that a superclass might expect to be handled by the method may not be present in the subclass version of the method. Test cases for the superclass may no longer be valid. Does the overriding method affect the object s state (especially from the view of the superclass)? If yes: be sure to run all test cases from the superclass. Dr. A. Williams, Fall 2008 Software Quality Assurance Lec 9 11 Example Class 2DPoint int x; int y; 2DPoint( int xvalue, int yvalue ) x = xvalue; y = yvalue; int getx() return x ; int gety() return y ; Class 3DPoint extends 2DPoint int z; 3DPoint( int xvalue, int yvalue, int zvalue ) super( xvalue, yvalue ); z = zvalue; int getz() return z ; In this case, the class 3DPoint provides an additional attribute that is independent of the superclass. Use of the superclass constructor should be checked in class 3DPoint: Check that values are passed to 2DPoint from 3DPoint Superclass methods do not need to be retested. Dr. A. Williams, Fall 2008 Software Quality Assurance Lec 9 12

7 Polymorphism / Dynamic Binding public void amethod( A obj ) // what gets called? obj.testme() If a variable is of type A, and the method testme()is called, there is more than one possible method that could be called. An object that is an instance of any subclass of A can be assigned to a variable of type A. We can only determine the actual method called at runtime. Dr. A. Williams, Fall 2008 Software Quality Assurance Lec 9 13 Polymorphism / Dynamic Binding Method testme() is polymorphic: Class of object A B C where called A A C Dr. A. Williams, Fall 2008 Software Quality Assurance Lec 9 14

8 Polymorphism / Dynamic Binding Strategy: Try a polymorphic method in (at least) two contexts where different methods will be used. Example: try the method with instances of A and C, to be sure those versions are used. May need to use combinatorial / pairwise approach with combinations of classes. Dr. A. Williams, Fall 2008 Software Quality Assurance Lec 9 15 Abstract classes Abstract classes cannot be instantiated, so objects of this type cannot be created. Methods in abstract classes may or may not be overridden, but they must be accessed from a subclass object. Abstract classes may still have constructors; these would be called from subclasses to do initialization that is expected to be common for all subclasses. Dr. A. Williams, Fall 2008 Software Quality Assurance Lec 9 16

9 Testing Abstract classes If class is abstract, derive a set of instantiations to cover significant cases. If available, can use some concrete classes from application. May need to create a subclass specifically for testing, that adds minimal functionality to be usable. A similar approach can be used for interfaces. Dr. A. Williams, Fall 2008 Software Quality Assurance Lec 9 17 Constructors and Destructors Constructors: Does the language require memory allocation? Was the right amount of memory requested? Was the requested amount available? What if it is not? Are all necessary values initialized? Are superclass constructors called correctly? Destructors: Are all contained objects destroyed as well? Are there resources that need to be cleaned up (network / database connections), etc.? Is the correct amount of memory released? Dr. A. Williams, Fall 2008 Software Quality Assurance Lec 9 18

10 Issues when testing constructors Is there an invisible default constructor? What if it were to be called by a subclass that doesn t yet exist? Do the constructors need to call superclass constructors explicitly? Are there several constructors? Do they interact with each other? Example: Class Obj int currentsize; Public Obj( ) this( 0 ); // calls other constructor Public Obj( int size ) currentsize = size; //... Dr. A. Williams, Fall 2008 Software Quality Assurance Lec 9 19 Memory leaks A memory leak is caused when memory is allocated for new objects, and then not released when objects are no longer needed. Some languages (Java, C#, Smalltalk) include automatic garbage collection which attempts to reclaim memory. When an object is no longer accessible, the object is eligible for garbage collection. In languages without automatic garbage collection (C, C++), memory leaks are a concern. Languages with garbage collection are not immune to memory leaks: if the program keeps references that are no longer being used, the garbage collector cannot recover the memory. Dr. A. Williams, Fall 2008 Software Quality Assurance Lec 9 20

11 When do memory leaks occur? Lost references: In C++, an object can no longer be located if there are no references to it, and the memory used by that object is no longer available. Example: Point p1 = new Point( 2, 1 ); Point p2 = new Point( 4, 3 ); p1 = p2; // reference to original p1 lost Object de-allocation: An object that creates other objects has to be sure to free those objects when it is itself de-allocated. What about collections? An object has to free exactly the same amount of memory as when it was allocated. Dr. A. Williams, Fall 2008 Software Quality Assurance Lec 9 21 Symptoms of memory leaks As memory is slowly lost, the amount of memory available for new objects will gradually shrink. Eventually this could be after weeks or months of continuous operation there isn t enough memory to fulfill a new request, and an out of memory error occurs in a constructor or when memory is allocated for an array. When the system is restarted, it will likely appear to run correctly. Memory leaks are difficult to detect, and to isolate. Specialized tools are available: Purify, from IBM/Rational Valgrind (open source, for Linux OS) Mozilla memory tools suite Dr. A. Williams, Fall 2008 Software Quality Assurance Lec 9 22

12 Generic Classes Classes with one or more parameters. Often used for collections. Example: The Java class HashMap<K,V>. Class has two parameters: K: key type for the map V: value type for the map. Purpose of the class is to keep a collection of (key,value) pairs. Method in the class: Public V get( K key ); Other features: Type-restricted parameters: AClass<T, S extends T> Wild card parameters: AClass<? extends Shape> // any type Dr. A. Williams, Fall 2008 Software Quality Assurance Lec 9 23 Testing Generic Classes Generic classes are similar to abstract classes; they cannot be instantiated on their own Try instantiating the class with representative classes as the parameter. Ones that are expected to be used. Class Object. Try a subclass of a parameter that has an extends clause. Dr. A. Williams, Fall 2008 Software Quality Assurance Lec 9 24

13 Classes with state If objects created from the class have state, build a state machine model of the class behaviour, and derive tests from it. Minimal coverage: a transition tour. Repeat state-based tests for subclasses. New tests specifically for subclasses may need to be added if there are additional states. Dr. A. Williams, Fall 2008 Software Quality Assurance Lec 9 25 Exceptions The use of exceptions can vastly increase the number of potential control flow paths. Exception handling can be chained. A calls B. B calls C. C throws an exception. B does not catch the exception In Java, method B would need a throws clause, even if the exception is not thrown within B. A catches the exception. Should all paths and / or chains be tested? Chained exceptions that pass through with no effect (such as B above) are usually not worth testing. Dr. A. Williams, Fall 2008 Software Quality Assurance Lec 9 26

14 Exceptions If exceptions are thrown within the class, try to arrange for them to be caused. This can be difficult in some cases. Effort needed to create the exception situation must be balanced against risk and the reliability of the test case to cause the exception on demand. If exceptions are caught in the class, check that the handling behaviour is appropriate. Safety-critical systems need careful testing of exception handling. Dr. A. Williams, Fall 2008 Software Quality Assurance Lec 9 27 Recovery from Exceptions When an exception is caught, be careful to ensure that the appropriate action is taken. Does the exception result in a graceful shutdown Network / database connections closed. Is there an attempt to restore the system to a usable state? Is the exception brought to the attention of a user? Dr. A. Williams, Fall 2008 Software Quality Assurance Lec 9 28