Object-Oriented Class Testing

• Object-oriented (OO) testing class testing is similar to unit testing in conventional software with some key differences.
• In conventional software the smallest testable unit is a function or module.
• In OO software the smallest testable unit is a class or object.
• Testing focus should be on each method of the class to ensure it performs correctly.
• The state behavior of the class must be correct as an object's behavior may change depending on its state.
• A challenge in class testing is determining the state of an object can be difficult.
• Additional methods might be required to check internal state variables during testing.

OO Class Testing Example

• Consider a bank account class with different states: open, deposit, withdraw, close.
• The states are: Open with positive balance, Open with negative or zero balance, and Closed.
• If an account has a zero or negative balance, withdrawals are restricted.
• If an account is positive, limited overdrafts may be allowed.
• A new method could be introduced to check the account state before operations.

Integration Testing in OO Software

• Unlike conventional software, hierarchical control structures are not present in OO systems, so traditional integration methods (top-down or bottom-up) do not apply.
• Two approaches to OO integration testing: Thread-based and Use-based.

Thread-based Testing

• Testing focuses on classes that work together to handle a single event/input.
• Each thread (sequence of related method calls) is tested individually.

Use-based Testing

• Testing begins with independent classes (those that do not depend on others).
• Once independent classes are tested, the next level of dependent classes is tested.

Validation Testing

• Validation testing ensures that software meets user requirements.
• Black-box testing techniques from traditional testing can be applied.
• Use cases are useful for designing test cases, as they represent real-world scenarios.

Test Cases and Class Hierarchy

• OO systems have class hierarchies, where methods may be inherited or redefined in subclasses.
• Redefined methods in subclasses need to be tested as they represent new code.
• Inherited methods should also be tested using a subset of original test cases to ensure they work correctly in subclasses.

Random Testing

• This involves generating random sequences of operations to test the system.
• It ensures different execution paths and interactions are exercised.
• It must consider the behavior lifecycle to ensure meaningful random tests.

Partition Testing

• It is used to divide the class behavior into different categories and test each category.

State-Based Partitioning

• The states of a class are identifiable.
• The operations which modify the state and operations which do not are determinable.
• Each method must be tested while the object is in each possible state.

Attribute-Based Partitioning

• It focuses on class attributes (variables).
• Methods are grouped based on whether they use or modify an attribute.
• Test cases are designed to cover each partition.

Category-Based Partitioning

• Methods are grouped into functional categories, such as: Initialization methods, Computational methods, Query methods, and Termination methods.
• Each category is tested separately.

Student Registration Example

• Consider a student registration class with the following methods: Add a class, Drop a class, Transfer sections, and List registered classes.

State-Based Partitioning in Student Registration

• Possible states are: Registered, On hold (cannot register), Full load (cannot register for more classes), Partial load (can register for more classes), and Freedom (can register freely).
• Events affecting state are: Register, Add class, Drop class, Transfer, Place hold, Release hold, and Graduate.
• Additional test methods to check state includes DisplayHold() and DisplayCredits().

OO Test Case Design

• OO test cases should be structured as follows:
  • Unique identifier – Every test case must be uniquely identified.
  • Class association – The test case must specify the class being tested.
  • Purpose – Clearly state the goal of the test.
  • Test components:
    • List of object states to be tested
    • List of methods/messages to be tested
    • List of exceptions that may occur
    • List of external conditions that may change (e.g., system environment)

Testing Methods in Different States

• Each method of a class should be tested in all relevant states.
• Additional methods may be required to retrieve and verify object states.
• Expected outcomes should account for state-dependent behavior.

Introduction to Object Orientation

• Object-oriented programming (OOP) is a paradigm that organizes software design around objects rather than functions and logic.
• It is becoming important because of:
  • Better organization and modularity
  • Encapsulation which protects data from unintended modifications
  • Reusability through inheritance which saves development effort
  • Polymorphism which provides flexibility in function calls
  • Real-world modelling which helps understand software structures
• Unlike traditional structured programming, OOP:
  • Uses objects instead of procedures
  • Groups data and methods together within classes
  • Emphasizes modelling real-world entities to improve system design

Classes and Objects

• A class is a template or blueprint for creating objects.
• An object is an instance of a class with its own unique state (data) and behavior (methods).
• A Courier Class groups different courier types, such as: "Book Courier", "Flower Courier", and "Pen Courier".
• Each courier has Attributes, such as Description, Dimensions, and Recipient Address, and Operations, such as Add, Delete, Update, and Get Status.

Inheritance

• It is the ability of a child class (subclass) to acquire the properties and methods of a parent class (superclass).

Types of Inheritance

• Single inheritance: One class derives from another.
• Multiple Inheritance: A class derives from multiple parent classes.
• Hierarchical Inheritance: A single class serves as a base for multiple derived classes.
• Example: Class FastTrackCourier (inherits CourierCompany)

Messages & Message Exchange

• Objects communicate via messages to perform operations.
• A message contains the Target Object (Receiver), Requested Operation (Method Name), and Additional Data (Parameters).
• In a courier tracking system, a Customer sends a message to the Courier System to getStatus(trackingNumber), after which the system processes the request and returns the delivery status.

Methods

• A method is a function defined in a class to operate on its objects.
• Methods allow objects to perform actions based on received messages.

Data Abstraction

• Hiding unnecessary details while exposing only the essential features.
• A user of a "Bank Account" class can check balance without seeing the internal database query.

Encapsulation

• This involves bundling data (attributes) and methods (functions) within a class while restricting direct access to some elements.
• Data Hiding ensures security by allowing only controlled access.
• For example, in Class BankAccount, balance is private and can only be modified using deposit() and withdraw().

Polymorphism

• This means one interface, multiple implementations.

Types of Polymorphism

• Compile-time (Method Overloading): The print() method works with both text and images.
• Runtime (Method Overriding): The speak() method has different implementations in different classes.

Object-Oriented Testing

• Object-oriented features like inheritance and polymorphism introduce testing challenges.

Activity Diagrams

• They are used to represent workflows in a system.
• Elements include States (Rounded boxes) which represent actions, Transitions (Arrows) which represent movement between states, and Forks & Joins which indicate parallel processing.
• Processing an order requires the following steps: Start → Receive Order → {Parallel: Fill Order | Handle Billing} → Ship Order → End.

Path Testing

• It ensures that all paths in a program are tested.
• Steps include: Drawing an Activity Diagram for a method, Computing Cyclomatic Complexity (Transitions - Activities + 2P), and Designing test cases for independent paths.

State-Based Testing

• It tests if the system behaves correctly based on its state and uses State Transition Diagrams.
• A State Transition Table is created for systematic testing.

Class Testing

• It is equivalent to Unit Testing in procedural programming.
• The goals are to verify that class implementation matches the specification and to ensure all methods and state transitions work correctly.
• Class developers usually perform this action by using test drivers that create object instances and call methods.

Testing Strategies for Classes

• Preconditions & Postconditions exist.
• Test cases must be identified.

State-Based Testing Strategies

• Exhaustive testing covers all paths, but is usually impractical.
• All-Transitions Testing ensures each transition is executed at least once.
• N+ Testing Strategy focuses on round-trip paths (paths that return to the same state).

Issues in Testing Object-Oriented Software

• OO software testing differs from traditional testing because of:
  • Unit definition changes where the smallest testable unit is usually a class or method instead of a function.
  • Testing focuses on how objects interact rather than breaking down functionality into smaller parts (Composition vs. Decomposition).
  • Call Graph-based integration is preferred over traditional functional decomposition-based integration.
• Properties that impact testing are:
  • Inheritance where methods from base classes must be tested across derived classes.
  • Encapsulation where private methods are difficult to test directly.
  • Polymorphism where the same method name behaves differently in different classes, requiring special test strategies.
• Message communication issues include:
  • Message quiescence, which ensures that messages do not remain unprocessed.
  • Event quiescence, which ensures that event-driven behaviors execute correctly.

Levels of Object-Oriented Testing

• Includes Unit Testing (Methods & Classes), Integration Testing (MM-Paths, Object Relationships), and System Testing (Threads, Use Cases, GUI interactions).
• Unit Testing covers statement-level execution inside individual methods or classes, and ensures that all methods function correctly.
• Method-Message (MM) Path Testing covers interactions between methods in a class and ensures proper message passing between objects.
• Thread Testing covers object interactions in multithreading environments and ensures that multiple threads communicate and execute correctly.

Reusable Testing Techniques for OO Software

• For Unit Testing, Code-based, Specification-based, and StateChart-based Testing are used.

• For Integration Testing,Call Graph-based Testing and MM-Path Testing are used.

• For System Testing, Use Case Testing and Model-Based Testing are implemented.

• StateChart-Based Testing is used to track the state of an object during execution.

• MM-Path Testing helps track the execution sequence of object messages.

Units in Object-Oriented Software

• In procedural programming, the smallest unit is a function or module.
• In OO programming, the smallest unit is a Method or Class.
• Candidate units in OO Software: A single method (useful for small functions), and a class (widely accepted in OO testing).

Single Method Testing

• It treats each method as an independent unit.
• It helps in large, complex classes where testing individual methods is useful.
• Reduces cyclomatic complexity.
• It requires intra-class integration testing.

Class Testing

• This is a more commonly used approach.
• In UML, the StateChart represents class behavior.
• Shifts complexity from unit testing to integration testing.

Composition and Encapsulation in Testing

• Stronger unit testing is needed when objects are composed of multiple smaller objects.
• Objects should maintain loose coupling and high cohesion to make testing easier.
• Encapsulation makes direct testing of internal class data difficult, thus using getters/setters or reflection-based testing is recommended.

Implications of Inheritance in Testing

• Base classes contain common methods, which are inherited by derived classes.
  • Inherited methods must be tested in every derived class.
  • Polymorphic methods behave differently across classes, requiring separate test cases.

Object-Oriented Testing Example: Windshield Wiper System

• Classes include Lever (Handles input from the user), Dial (Controls the speed settings), and Wiper (Implements speed changes based on lever and dial).
• Challenges include which unit controls the interactions and if mock objects are needed to simulate inputs.
• Sate based testing ensures correct behavior as the lever and dial are moved.

Unit Testing in Object-Oriented Software

• Difficulties include that private attributes cannot be tested directly and that methods may depend on other objects.
• Solutions include using mock objects to simulate dependencies and creating test harnesses to test private methods.

StateChart-Based Testing

• It is used for system-level validation.
• StateChart diagrams represent object transitions.

Integration Testing for OO Software

• Challenges include low cyclomatic complexity in methods and higher complexity at the integration level.
• Techniques include Call Graph-Based Integration Testing and MM-Path Testing (tracks message interactions between objects).

Message-Method Paths (MM-Paths) in OO Testing

• It tracks the sequence of method calls connected by messages.

System Testing for OO Software

• This ensures that the entire system behaves correctly.
• Sources for Test Cases include Use Cases and Model-Based Testing.

Message Passing & Data Flow Testing

• It tracks interactions between objects via messages.
• It extends Event-Driven Petri Nets to model OO behavior.
• Testing complexity shifts from methods to integration.
• Encapsulation helps, but makes internal testing harder.
• Dataflow testing is important for integration.
• Model-based testing still lacks strong integration support.

Introduction to Use Case Testing

• Use Case Testing is a black-box testing technique used to verify system functionality by testing interactions between actors (users or external systems) and use cases.
• It helps in requirement elicitation and modeling, ensuring that the system meets functional requirements. Key Characteristics:
  • It focuses only on functional requirements.
  • It captures user expectations and system interactions.
  • It helps in defining clear acceptance criteria for system functionality.
• Advantages include that it ensures user-focused testing, identifies missing requirements early, defines real-world scenarios, and provides better test coverage compared to traditional test case writing.

Use Case Diagram

• It is a graphical representation of system functionality, providing a top-level view of interactions between users (actors) and system functionalities (use cases).
• It helps in requirement validation by visualizing system operations.

Components of a Use Case Diagram

• Actors: External entities (users, systems, devices) interacting with the system.
• Use Cases: Functionalities or actions performed by the system.
• Relationships: Connections between actors and use cases.

Actors in Use Case Testing

• An actor represents any user, external system, or device interacting with the system.
• Actors are external to the system but play a role in triggering or receiving system actions.
• Types of actors include primary and secondary.

What is a Use Case?

• Describes how a system interacts with an actor to achieve a goal.
• It defines the expected sequence of events between the system and actor.
• Key Components: Use Case Name, Actors, Preconditions, Basic Flow, Alternative Flow, and Postconditions.

Use Case Flows

• The basic flow is the primary sequence of interactions leading to a successful outcome.
• The alternate flow occurs when unexpected conditions arise.

Use Case Template Structure

• Key Elements of a Use Case Document:
  • A brief description that summarises the use case
  • Names the actors, users or external systems interacting with the system
  • Flow of events includes a basic flow which describes the normal execution path, and alternate flows for error handling or deviations
  • Special Requirements: Business rules, security constraints.
  • Pre-conditions, the conditions before execution
  • Post-conditions, the expected system state after execution
  • Extension Points, additional behaviors connected to this use case

Relationship Between Use Cases & Actors

• The relationship can be described as includes, extends, or generalization.
• Includes means one use case is part of another.
• Extends means one use case adds functionality to another.
• Generalization means use cases inherit from a parent use case.

Generating Test Cases from Use Cases

• Test cases can be generated by these steps:
  • Identifying the preconditions
  • Defining basic flow test scenarios
  • Identifying alternate flows and test cases
  • Defining expected outputs and system behavior

Use Case Scenarios

• A scenario is an instance of a use case, representing a specific execution path.

Applicability of Use Case Testing

• It is best for early testing, and is available after finalizing SRS.
• Helps identify defects early.
• It improves reliability, efficiency, and user experience.