Guías de Pruebas en Programación Orientada a Objetos

Object-Oriented Testing Guidelines

• Evaluate correctness and consistency of Object-Oriented Analysis (OOA) and Object-Oriented Design (OOD) models.
• Testing strategies change due to encapsulation and inheritance.
• Unit testing focuses on class operations and state behavior.
• Integration testing focuses on classes in usage scenarios.
• Validation uses black-box methods.

OOT Strategy

• Encapsulation hides data members, requiring tests for access methods and hidden data structures.
• Inheritance and polymorphism require context-specific tests for derived classes. Multiple inheritance further complicates testing.

Testing Approach

• Class Testing (Unit Testing): Focuses on class operations and state behavior.
• Integration Testing:
  • Thread-based Testing: Integrates classes needed for a single input/event.
  • Use-based Testing: Integrates classes needed for a single use case.
  • Cluster Testing: Integrates classes demonstrating collaboration.

Test Case Design

• Each test case should be uniquely identified and explicitly linked to the class being tested.
• Clearly state the purpose of each test case.
• Detail steps including object states, messages, operations, exceptions, and external conditions, plus supplementary information.

Test Methods

• Random Testing: Identifies operations, constraints, and valid random test sequences.
• Partition Testing: Categorizes and tests operations based on their ability to change class state, use attributes, and perform functions.
• Inter-Class Testing: Generates random test sequences involving client and server classes, tracking messages and operators.

Object-Oriented Metrics

• Conventional Lines of Code (LOC) are less useful in OO projects. Alternative Object-Oriented metrics include:
  • Number of Scenario Scripts: Describes user-application interactions.
  • Number of Key Classes: Highly independent components.

Project Estimation

• Use OO-specific techniques alongside conventional methods for better estimations.
• An effort estimation formula exists: E = w × (k + s)
  • E = estimated effort
  • k = number of key classes
  • w = average person-days per class
  • s = number of support classes (estimated as m × k, where m is a multiplier based on interface type)

Technical Metrics (Chidamber and Kemerer Metric Suite)

• Weighted Methods per Class (WMC): Measures complexity of all methods in a class. Low WMC indicates better design, reusability, and testability.
• Depth of Inheritance Tree (DIT): Maximum length from the base class to the derived classes (leaf nodes). Large DIT indicates greater design complexity.
• Number of Children (NOC): Number of derived classes from a given class. Although higher NOC suggests better reuse, more complex testing might be needed.
• Coupling between Object Classes (CBO): Number of collaborators for a class. High CBO values indicate less reusability.
• Response Set for a Class (RFC): Number of methods that can react to messages. Higher RFC indicates more testing effort required.
• Lack of Cohesion in Methods (LCOM): High LCOM implies that methods are too loosely related, often calling for further class decomposition.

Design Metrics

• Class Size (CS): Count of operations and attributes; significant CS might indicate excess responsibility within a class.
• Number of Operations Overridden by a Subclass (NOO): High NOO often signals issues with maintaining abstraction in the class hierarchy.

Additional Metrics

• Number of Support Classes: Classes supporting the system unrelated to the core problem domain.
• Average number of Support Classes per Key Class: Relationship between support and core classes.
• Number of Subsystems: Aggregation of classes with common functionality.
• Number of Operations Added by a Subclass (NOA): Shows drift of subclass from superclass.
• Specialization Index (SI): Indicates how well a class adheres to the superclass abstraction. Higher values generally indicate less adherence.
• Average Operation Size (OS): LOC or messages sent by operations in a class.
• Operation Complexity (OC): Any complexity measure, preferably kept low.
• Average Number of Parameters per Operation (NP): Should generally be low.
• Lack of Cohesion in Methods (LCOM): Measures the interaction of methods within a class and identifies potential cohesion issues.
• Percent Public and Protected (PAP): Ratio of public/protected attributes to private attributes; High PAP often implies potential side effects between classes.
• Public Access to Data Members (PAD): Number of classes accessing another class's attributes; high PAD values can suggest potential side effects among classes.
• Number of Root Classes (NOR): Testing effort may increase with the number of classes at the root of a hierarchy.
• Fan In (FIN): Indicates multiple inheritance.
• Number of Children (NOC) and Depth of Inheritance Tree (DIT): Indicates complexity and potential coupling issues in a hierarchy.

Este cuestionario evalúa las estrategias de pruebas en modelos de Análisis y Diseño Orientado a Objetos. Se discuten enfoques como pruebas unitarias e integradas, abordando aspectos como encapsulación e herencia. Ideal para quienes buscan profundizar en el testing de clases y su comportamiento en diferentes escenarios.