Introduction to Testing in Object-Oriented Applications
Welcome to this guide on testing! Whether you are writing a simple class or developing a large-scale software system, testing is one of the most critical phases in the software development lifecycle. Testing ensures that your application behaves correctly, handles errors gracefully, and meets the end-user's requirements before it goes live.
Don't worry if software testing seems like a massive topic at first. In this chapter, we will break down the core levels of testing, explore how to design effective test data, look at specific challenges that come with testing Object-Oriented (OO) code, and learn how to construct formal test plans.
1. The Hierarchy of Testing Levels
In Software Systems Development, testing happens systematically in stages. We start by testing the smallest pieces of code and gradually work our way up to the entire completed system.
Level 1: Unit Testing
Unit Testing is the process of testing individual components, methods, functions, or classes in total isolation from the rest of the application. The goal is to verify that the internal logic and state transitions work strictly according to design.
Analogy: Imagine building a car. Before assembling the vehicle, you test the spark plugs, the battery, and the alternator individually on a workbench to make sure each single part works on its own.
In an Object-Oriented Context: Testing an isolated class involves:
• Instantiating the class to create an object.
• Setting up its initial internal state via constructors or properties.
• Invoking specific methods using test inputs.
• Verifying the returned outputs and internal state changes.
Level 2: Integration Testing
Integration Testing involves combining two or more tested units or classes and verifying their interactions, interfaces, and data transfers. It ensures that components communicate with each other seamlessly without data loss or interface mismatches.
There are two primary approaches to Integration Testing:
• Top-Down Integration: Modules are integrated starting from the top-level control structures downward. Any lower-level modules that are not yet developed are simulated using temporary placeholder code called stubs.
• Bottom-Up Integration: Modules are integrated starting from the lowest-level helper classes upward. Temporary calling programs or test harnesses (drivers) are used to simulate the higher-level calling modules.
Level 3: System Testing
System Testing evaluates the complete, fully integrated software system as a whole. It tests the application against all functional requirements (what the system should do) and non-functional requirements (such as performance, security, and usability) in an environment that closely mimics the live runtime environment.
Level 4: Acceptance Testing (User Acceptance Testing / UAT)
Acceptance Testing is conducted with or by the end user or client. Its purpose is to evaluate whether the application meets the agreed business requirements and acceptance criteria before final sign-off, purchase, or deployment.
Key Takeaway: Remember the progression from smallest to largest: Unit (individual classes/methods) \(\rightarrow\) Integration (interfaces between classes) \(\rightarrow\) System (entire software package) \(\rightarrow\) Acceptance (client validation).
2. Testing Strategies and Approaches
Black-Box Testing vs. White-Box Testing
• Black-Box Testing (Functional / Specification-Based): The tester evaluates the system purely based on inputs and outputs without any knowledge of the internal code, algorithms, or structural logic. Test cases are derived strictly from the specification requirements.
• White-Box Testing (Structural Testing): The tester has full visibility of the source code. Test cases are designed to test internal structures, execution paths, logic branches, loops, and conditions to ensure all code statements execute correctly.
Alpha Testing vs. Beta Testing
• Alpha Testing: An internal acceptance testing phase carried out by in-house developers and test teams in a controlled environment before releasing the software externally.
• Beta Testing: A pre-release testing phase where a near-final version of the software is released to a select group of external end-users in a real-world operating environment to uncover unexpected issues and gather feedback.
3. Designing Test Data Classifications
When testing input fields or validation routines, examiners will expect you to choose appropriate test data from three standard classifications. Let's look at an example where an input field requires an Age between \(18\) and \(65\) (inclusive):
1. Normal (Valid) Data:
Typical, everyday values that fall comfortably within the acceptable boundaries of the system.
Example for Age (18 to 65): \(30\), \(45\)
2. Boundary (Extreme) Data:
Values positioned at the outer limits and exact edges of both valid and invalid ranges.
Example for Age (18 to 65): \(17\) (just below minimum), \(18\) (minimum valid), \(65\) (maximum valid), \(66\) (just above maximum)
3. Erroneous (Invalid) Data:
Values that are completely outside the acceptable range or contain an incorrect data type.
Example for Age (18 to 65): \(-5\), \(100\), "twenty"
Key Takeaway: Always test both sides of a boundary! If a valid range is \(18\) to \(65\), test \(17\), \(18\), \(65\), and \(66\).
4. Object-Oriented Specific Testing Considerations
Testing in an Object-Oriented environment introduces specific challenges that are not present in traditional procedural programming:
• Encapsulation: In OO programming, attributes are typically declared as private to prevent unauthorized direct modification. Because these internal fields cannot be accessed directly from outside the class, testers must inspect the object's state indirectly by calling public getter methods or checking the return values of public methods.
• State-Dependent Behavior: An object's behavior depends directly on its internal state (the current values held in its fields). For example, calling an account.withdraw(50) method will behave differently if the balance is \(\$100\) compared to when the balance is \(\$20\). Therefore, test cases must explicitly place the object into a predetermined initial state before executing a test method.
• Inheritance and Polymorphism: When a subclass overrides a method from a parent class, that overridden method must be tested independently. You cannot assume that because the base class method works, the derived class will work correctly. Polymorphic method calls must be tested across different subclass types to ensure dynamic binding executes properly.
5. Structuring a Standard Test Plan
In CCEA AS 1 examinations, you are frequently required to design or complete a formal test plan. A standard test table must include the following seven columns:
1. Test ID / Number: A unique identifier for the test case (e.g., T01, T02).
2. Test Purpose / Description: A clear statement of what is being tested (e.g., "Verify age validation rejects values under 18").
3. Test Data / Input: The exact values or inputs supplied during the test (e.g., \(17\)).
4. Expected Result: The precise, measurable outcome expected if the software functions correctly (e.g., "Displays error: 'Age must be between 18 and 65' and resets input field").
5. Actual Result: The real outcome observed when the test is executed (e.g., "Error message displayed and focus reset").
6. Pass / Fail: Indicates whether the Actual Result matched the Expected Result.
7. Remedial Action / Comments: Notes on what needs to be fixed if the test failed, or notes on test conditions.
6. Common Pitfalls and Examiner Tips
• Avoid Vague Expected Results: Never write generic phrases like "It works", "Pass", or "Shows error" in a test plan. Examiners look for detailed, precise outcomes, such as "Calculates discount of 10% and updates total to \$45.00".
• Do Not Confuse Integration and System Testing: Integration testing is specifically focused on the interfaces and communication between interacting units/classes. System testing is the evaluation of the complete, unified application against the overall specification.
• Always Include Boundary Values: When asked to produce a set of test cases, candidates often provide only normal and erroneous data while forgetting boundary/extreme values.
• Remember Object State: Always remember that an object's method cannot be tested in a vacuum—its behavior depends on the values of the instance variables set before the method runs.