Object Oriented Testing in Software Testing

Prerequisite – Software Testing
Software typically undergoes many levels of testing, from unit testing to system or acceptance testing. Typically, in-unit testing, small “units”, or modules of the software, are tested separately with a focus on testing the code of that module. In higher-order testing (e.g, acceptance testing), the entire system (or a subsystem) is tested with a focus on testing the functionality or external behavior of the system.

As information systems are becoming more complex, the object-oriented paradigm is gaining popularity because of its benefits in analysis, design, and coding. Conventional testing methods cannot be applied for testing classes because of problems involved in testing classes, abstract classes, inheritance, dynamic binding, message passing, polymorphism, concurrency, etc.
Testing classes is a fundamentally different issue than testing functions. A function (or a procedure) has a clearly defined input-output behavior, while a class does not have an input-output behavior specification. We can test a method of a class using approaches for testing functions, but we cannot test the class using these
approaches.

• Data dependencies between variables
• Calling dependencies between modules
• Functional dependencies between a module and the variable it computes
• Definitional dependencies between a variable and its types.

But in Object-Oriented systems, there are the following additional dependencies:

• Class-to-class dependencies
• Class to method dependencies
• Class to message dependencies
• Class to variable dependencies
• Method to variable dependencies
• Method to message dependencies
• Method to method dependencies

Issues in Testing Classes:

Additional testing techniques are, therefore, required to test these dependencies. Another issue of interest is that it is not possible to test the class dynamically, only its instances i.e, objects can be tested. Similarly, the concept of inheritance opens various issues e.g., if changes are made to a parent class or superclass, in a larger system of a class it will be difficult to test subclasses individually and isolate the error to one class. In object-oriented programs, control flow is characterized by message passing among objects, and the control flow switches from one object to another by inter-object communication. Consequently, there is no control flow within a class like functions. This lack of sequential control flow within a class requires different approaches for testing. Furthermore, in a function, arguments passed to the function with global data determine the path of execution within the procedure. But, in an object, the state associated with the object also influences the path of execution, and methods of a class can communicate among themselves through this state because this state is persistent across invocations of methods. Hence, for testing objects, the state of an object has to play an important role. Techniques of object-oriented testing are as follows:

1. Fault Based Testing: This type of checking permits for coming up with test cases supported the consumer specification or the code or both. It tries to identify possible faults (areas of design or code that may lead to errors.). For all of these faults, a test case is developed to “flush” the errors out. These tests also force each time of code to be executed. This method of testing does not find all types of errors. However, incorrect specification and interface errors can be missed. These types of errors can be uncovered by function testing in the traditional testing model. In the object-oriented model, interaction errors can be uncovered by scenario-based testing. This form of Object oriented-testing can only test against the client’s specifications, so interface errors are still missed.
2. Class Testing Based on Method Testing: This approach is the simplest approach to test classes. Each method of the class performs a well defined cohesive function and can, therefore, be related to unit testing of the traditional testing techniques. Therefore all the methods of a class can be involved at least once to test the class.
3. Random Testing: It is supported by developing a random test sequence that tries the minimum variety of operations typical to the behavior of the categories
4. Partition Testing: This methodology categorizes the inputs and outputs of a category so as to check them severely. This minimizes the number of cases that have to be designed.
5. Scenario-based Testing: It primarily involves capturing the user actions then stimulating them to similar actions throughout the test. These tests tend to search out interaction form of error.

Purpose of Object Oriented Testing

1. Object Interaction Validation: Check to make sure objects interact with one another appropriately in various situations. Testing makes ensuring that the interactions between objects in object-oriented systems result in the desired results.
2. Determining Design Errors: Find the object-oriented design’s limitations and design faults. Testing ensures that the design complies with the desired architecture by assisting in the identification of problems with inheritance, polymorphism, encapsulation and other OOP concepts.
3. Finding Integration Problems: Evaluate an object’s ability to integrate and communicate with other objects when it is part of a bigger component or subsystem. This helps in locating integration difficulties, such improper method calls or issues with data exchange.
4. Assessment of Reusable Code: Evaluate object-oriented code’s reusability. Code reuse is promoted by object-oriented programming via features like inheritance and composition. Testing ensures that reusable parts perform as intended in various scenarios.
5. Verification of Handling Exceptions: Confirm that objects respond correctly to error circumstances and exceptions. The purpose of object-oriented testing is to make sure that the software responds carefully and is durable in the face of unforeseen occurrences or faults.
6. Verification of Uniformity: Maintain uniformity inside and between objects and the object-oriented system as a whole. Maintainability and readability are enhanced by consistency in naming standards, coding styles and compliance to design patterns.