PT

12.3 Program Testing & Maintenance

Understanding ways of exposing and avoiding faults in programs, testing methods, and program maintenance

Learning Objectives

By the end of this lesson, you will be able to:

  • Show understanding of ways of exposing and avoiding faults in programs
  • Locate and identify different types of errors e.g. syntax errors, logic errors, run-time errors
  • Show understanding of methods of testing and select appropriate data for given methods
  • Show understanding of the need for a test strategy/test plan and their likely contents
  • Choose appropriate test data including normal, abnormal and extreme/boundary
  • Show understanding of need for continuing maintenance of a system and differences between each type of maintenance
  • Analyse an existing program and make amendments

Key Terms

Syntax Error

Error in the grammar of a source program, where a statement doesn't follow programming language rules

Logic Error

Error in the logic of a program, meaning the program doesn't do what it's supposed to do

Run-time Error

Error that happens when program executes an invalid instruction (e.g., divide by zero, out of bounds)

Debugging

Process of finding and correcting errors (bugs) in a program

Dry Run / Walkthrough

Checking an algorithm works as intended using a trace table and different test data

Trace Table

Table showing process of dry-running a program with columns showing values of each variable as it changes

Black-box Testing

Testing focused on functionality without considering internal code structure

White-box Testing

Testing that involves knowledge of code and checks every path through the code

Integration Testing

Testing the whole program when modules are joined together

Stub Testing

Testing technique using dummy modules during development of modular programs

Alpha Testing

Testing software in-house by software testers before release to customers

Beta Testing

Testing by limited audience of potential users after alpha testing

Acceptance Testing

Testing by customer to check bespoke software meets requirements before sign-off

Patch

Small program released by developers to run with an existing program to correct an error

Corrective Maintenance

Maintenance to correct errors that appear during use

Perfective Maintenance

Maintenance to improve performance of a program during its use

Adaptive Maintenance

Maintenance to alter a program so it can perform new tasks required by customer

Ways of Avoiding and Exposing Faults in Programs

Most programs written will contain errors, as programmers are human and do make mistakes. A program fault is something that makes program not do what it is supposed to do under certain circumstances.

Fault Avoidance

Starts with provision of comprehensive and rigorous program specification at end of analysis phase of program development lifecycle:

  • Use of formal methods such as structure charts, state-transition diagrams and pseudocode at design stage
  • At coding stage, use of programming disciplines such as information hiding, encapsulation and exception handling
  • All help to prevent faults before they occur

Fault Exposure

Faults or bugs in a program are then exposed at testing stage:

  • Testing will show presence of faults to be corrected
  • Cannot guarantee that programs are fault free under all circumstances
  • Faults can appear during lifetime of a program and may be exposed during live running
  • Faults are then corrected as part of maintenance stage of program lifecycle

Debugging Simulation: Finding Errors

Try to find the errors in this simple Python program that calculates the average of three numbers:

# Python program to calculate average of three numbers
def calculate_average(num1, num2, num3):
total = num1 + num2 + num3 # Line 2
average = total / 3 # Line 3
return average # Line 4
# Main program
numbers = [10, 20, 30]
result = calculate_average(numbers[0], numbers[1], numbers[3]) # Line 8
print("The average is: " + result) # Line 9

Real-Life Example: Online Exam System

Consider an online exam system used by schools:

Fault Avoidance

Clear specification: "System must allow 100 students simultaneously, handle network disconnections, prevent cheating"

Testing Phase

Test with 101 students (extreme data), simulate network failure, try to copy-paste answers

Live Running

During real exam, a bug causes timer to freeze for some students → patch released overnight

This shows how faults are avoided through good design, exposed through testing, and may still appear in live use requiring maintenance.

Check Your Understanding: Faults & Debugging

Answer
  • [1 mark] Debugging is the process of finding and correcting errors (bugs) in a program
  • [Additional] An IDE contains features to help with debugging such as breakpoints and step-through execution
Answer
  • [1 mark] Information hiding
  • [1 mark] Exception handling
  • [Additional] Also: encapsulation, modular programming, defensive programming
Answer
  • [1 mark] Testing can only show the presence of faults, not their absence
  • [1 mark] It's impossible to test every possible combination of inputs and conditions
  • [Additional] Some faults may only appear under very specific circumstances not covered in testing
Answer
  • [1 mark] Faults that appear during the program's lifetime are corrected
  • [1 mark] The program may be updated or patches may be sent out to customers
  • [Additional] Maintenance ensures the program continues to work correctly as requirements or environments change

Types of Errors

There are three main types of errors that can occur in programs. Understanding these helps in identifying and fixing them efficiently.

Syntax Errors

Errors in grammar of a source program:

  • Program statement doesn't follow rules of programming language
  • Example: incorrect spelling of a keyword
  • Checked during coding phase of program development lifecycle
  • Must be corrected before program can be executed
  • IDEs offer suggestions about what syntax errors are and how to correct them

Example: In Python: prin("Hello") instead of print("Hello")

Logic Errors

Errors in logic of a program:

  • Program doesn't do what it's supposed to do
  • Usually found when program is being tested
  • IDEs allow us to single step through a program to find errors
  • Can work through program using trace table
  • Trace tables show process of dry-running a program

Example: Calculating average: (a + b) / 2 instead of (a + b + c) / 3 for three numbers

Run-time Errors

Happen when program executes an invalid instruction:

  • Out of bounds error or attempts to divide by zero
  • Program may halt unexpectedly or go into infinite loop
  • If tested in IDE, error may be managed with suitable error message
  • If program released and error occurs, developer should be informed
  • Patch can be sent out to all customers to solve problem

Example: result = 10 / 0 causes "ZeroDivisionError" at runtime

Why Errors Occur and How to Find Them

Software may not perform as expected for a number of reasons:

  • Programmer has made a coding mistake
  • Requirement specification was not drawn up correctly
  • Software designer has made a design error
  • User interface is poorly designed, and the user makes mistakes
  • Computer hardware experiences failure

How Are Errors Found?

The end user might report an error. This is not good for reputation of software developer.

Important: Research shows the earlier an error can be found, the cheaper it is to fix.

Purpose of testing is to discover errors. Program testing can be used to show presence of bugs, but never to show their absence.

Key Principle: Test throughout development, not just at the end.

Activity 1: Identify Error Types

For each scenario below, identify whether it's a syntax error, logic error, or runtime error:

  1. A program to calculate area of circle uses formula area = 2 * 3.14 * radius instead of area = 3.14 * radius * radius
  2. In Python: x = input("Enter number: "); y = x + 5 (user enters "10", program crashes)
  3. Missing semicolon at end of line in Java: System.out.println("Hello")
  4. Accessing array element at index 10 when array only has 5 elements
  5. Program to find maximum of two numbers always returns the second number, even when first is larger
Solution:
  1. Logic Error - The formula is wrong (using circumference formula instead of area), but the syntax is correct. Program will run but give wrong results.
  2. Runtime Error - The program will run initially, but crash when trying to add string "10" to integer 5 (TypeError in Python).
  3. Syntax Error - Missing semicolon violates Java's grammar rules. Program won't compile.
  4. Runtime Error - Array index out of bounds. Program will run but crash when accessing index 10.
  5. Logic Error - Program runs without syntax errors but gives incorrect results due to flawed logic.

Dry-run / Trace Table Simulation

Step through this algorithm to understand how a trace table works. This helps find logic errors by tracking variable values.

INPUT Number1, Number2, Number3
IF Number1 > Number2
THEN // Number1 is bigger
IF Number1 > Number3
THEN
OUTPUT Number1
ELSE
OUTPUT Number3
ENDIF
ELSE // Number2 is bigger
IF Number2 > Number3
THEN
OUTPUT Number2
ELSE
OUTPUT Number3
ENDIF
ENDIF
Trace Table:
Line of algorithm Test1 Test2 Test3 Test4
INPUT Number1 15 12 12 8
INPUT Number2 12 8 15 12
INPUT Number3 8 15 8 15
IF Number1 > Number2 TRUE TRUE FALSE FALSE
THEN TRUE FALSE
IF Number1 > Number3
THEN Output 15
OUTPUT Number1
ELSE Output 15
OUTPUT Number3
ENDIF
ELSE TRUE FALSE
IF Number2 > Number3
THEN Output 15
OUTPUT Number2
ELSE Output 15
OUTPUT Number3
ENDIF

How dry-running works:

  • Write down current contents of all variables and conditional values at each step
  • Test1: 15 > 12 (TRUE), 15 > 8 (TRUE) → Output 15 (correct, 15 is largest)
  • Test2: 12 > 8 (TRUE), 12 > 15 (FALSE) → Output 15 (correct, 15 is largest)
  • Test3: 12 > 15 (FALSE), go to ELSE, 15 > 8 (TRUE) → Output 15 (correct)
  • Test4: 8 > 12 (FALSE), go to ELSE, 12 > 15 (FALSE) → Output 15 (correct)
  • This algorithm correctly finds the largest of three numbers

Real-Life Example: Banking App

A mobile banking app experiences different types of errors:

Syntax Error

Developer types transferFund(frm, to, ammount) instead of transferFund(from, to, amount). App won't compile for release.

Logic Error

Interest calculation uses balance * 0.05 instead of balance * 0.05 / 12 for monthly interest. App runs but shows wrong interest.

Runtime Error

User enters negative amount for transfer: newBalance = oldBalance - amount causes unexpected behavior. App crashes during use.

The syntax error is caught before release, logic error might be found in testing, runtime error might only appear when real users try unusual inputs.

Check Your Understanding: Error Types

Answer
  • [1 mark] Syntax error: Error in grammar of program, violates language rules, program won't run
  • [1 mark] Logic error: Error in program logic, program runs but gives wrong results
  • [1 mark] Syntax errors caught during compilation, logic errors found during testing
Answer
  • [1 mark] Division by zero (e.g., 10 / 0)
  • [1 mark] Array index out of bounds (accessing element 10 in array of size 5)
  • [Additional] Also: file not found, insufficient memory, network connection lost
Answer
  • [1 mark] A table showing process of dry-running a program with columns showing values of each variable as it changes
  • [1 mark] Used to check that an algorithm works as intended by manually stepping through it with test data
  • [Additional] Also known as a walkthrough, helps find logic errors
Answer
  • [1 mark] Less code has been written, so fewer changes needed to fix the error
  • [1 mark] Finding errors after release requires patches, customer support, and can damage reputation
  • [Additional] Errors found in design phase are cheaper to fix than those found in testing or live use
Answer
  • [1 mark] A patch is a small program released by developers to run with an existing program
  • [1 mark] Used to correct an error or provide extra functionality after the program has been released
  • [Additional] Patches fix runtime errors or security issues found in live software

Testing Methods

Programs need to be tested before they are released. Tests begin from moment they are written; they should be documented to show that program is robust and ready for general use.

Testing Methods Overview

Stub Testing

  • Employed during development of modular programs
  • Tests conducted even before all modules have been fully implemented
  • A dummy module is created to simulate or replace actual module or subroutine
  • Dummy module typically contains an output statement or returns a fixed value
  • Indicates that call to the module has been made

Example: Testing login system before payment module is ready. Stub returns "Payment successful" without actually processing payment.

Black-box Testing

  • Focused on functionality without considering internal code structure
  • Test cases designed based on software's specifications and requirements
  • Testers do not have access to internal workings of software
  • Primary goal: ensure software functions correctly from user's perspective
  • Helps identify errors and discrepancies between expected and actual behavior

Example: Testing a calculator app by entering numbers and operations, checking outputs match expected results.

White-box Testing

  • Testing involves knowledge of the internal code structure
  • Suitable test data chosen to check every path through the code
  • Programmer can see the code being tested
  • Tests all logical paths, branches, and conditions in the code
  • Example provided in the PDF tests all paths of a 3-number comparison

Example: Testing all IF-ELSE branches in the 3-number comparison algorithm shown earlier.

Integration Testing

  • Software consists of many modules written by different programmers
  • Each individual module might have passed all tests
  • When modules are joined together, whole program must be tested
  • Usually done incrementally (add modules one by one and test)
  • Ensures modules work together correctly

Example: Testing login module with database module, then adding payment module, then adding reporting module.

Testing Levels Simulation

Visualize how different testing methods fit into the software development process:

1
Unit Testing

Individual modules tested in isolation

2
Integration Testing

Modules combined and tested together

3
System Testing

Complete system tested as a whole

Alpha Testing

Software tested in-house by software testers before release to customers

Beta Testing

Version released to limited audience of potential users (beta testers)

Acceptance Testing

Bespoke software tested by customer to check it meets requirements

Testing Process:
  • Alpha Testing: In-house testing by company's own testers. Finds major bugs before customers see the software.
  • Beta Testing: Limited release to real users. Tests in real environments, gets feedback on usability and finds edge cases.
  • Acceptance Testing: Customer tests bespoke software against their requirements before signing off (approving) the software.
  • Sign-off: Customer approves software after successful acceptance testing.

Activity 2: Select Testing Methods

For each scenario, recommend the most appropriate testing method(s) and explain why:

  1. A banking application needs to be tested for security vulnerabilities before release to the public.
  2. A team is developing a large e-commerce website with 20 different modules (login, cart, payment, etc.).
  3. A custom inventory management system is being built for a specific supermarket chain.
  4. A mobile game developer wants real user feedback before the official launch.
  5. A programmer is testing their own code for a function that calculates tax based on multiple conditions.
Solution:
  1. Black-box + Alpha testing - Black-box testing to check functionality from user perspective without knowing internal code. Alpha testing by security experts to find vulnerabilities before public release.
  2. Stub testing + Integration testing - Stub testing to test modules before all are complete. Integration testing to ensure all 20 modules work together correctly when combined.
  3. Acceptance testing - Since it's bespoke software for a specific customer, they need to test it meets their requirements before signing off and paying for it.
  4. Beta testing - Releasing to a limited audience of real users gets feedback on gameplay, difficulty, and finds bugs in real-world use before official launch.
  5. White-box testing - The programmer knows the code and needs to test all paths through the tax calculation logic (all IF conditions and branches).

Test Plan and Strategy

During design stage of a software project, a suitable testing strategy must be worked out to ensure testing of software from very beginning. We need a test plan with likely contents:

Test Plan Contents:
  • Flow of Control: Does user get appropriate choices and does chosen option go to correct module?
  • Validation of input: has all data been entered into system correctly?
  • Do loops and decisions perform correctly?
  • Is data saved into correct files?
  • Does system produce correct results?
Test Data Selection:
  • Select test data that will allow us to see whether it is handled correctly
  • Test with normal (valid) data
  • Test with abnormal (erroneous) data
  • Test with boundary (extreme) data
Type of test data Explanation Example (Age validation: 18-65)
Normal (valid) Typical data values that are valid 25, 30, 45 (within range)
Abnormal (erroneous) Data values that system should not accept "abc", -5, 12 (non-numeric, negative, under 18)
Boundary (extreme) Data values that are at a boundary or an extreme end of range 18, 65, 0, 100 (exact boundaries and extremes)

Real-Life Example: Online Shopping Website

An e-commerce website goes through comprehensive testing:

Test Plan Example:
  • Flow of Control: Can user browse → add to cart → checkout → pay?
  • Validation: Does it reject invalid credit card numbers or future expiry dates?
  • Loops/Decisions: Does "Apply discount" work correctly for eligible users?
  • Data Saving: Are orders saved to database correctly?
  • Results: Does total price calculate correctly with tax and shipping?
Test Data Examples:
Normal:

Add 2 items ($10 each), apply $5 discount = $15 total

Abnormal:

Try to add -3 items to cart, enter "ABC" as quantity

Boundary:

Apply 100% discount (free), cart with 999 items

The website would use stub testing for payment gateway during development, integration testing when combining cart+payment+inventory modules, beta testing with real users, and acceptance testing if built for a specific retailer.

Check Your Understanding: Testing Methods

Answer
  • [1 mark] Black-box: Tests functionality without knowing internal code structure
  • [1 mark] White-box: Tests with knowledge of code, checks all paths through code
  • [1 mark] Black-box: From user perspective; White-box: From programmer perspective
Answer
  • [1 mark] During development of modular programs, before all modules are fully implemented
  • [1 mark] To test a module that depends on another module that isn't ready yet
  • [Additional] Uses dummy modules that return fixed values to simulate real modules
Answer
  • [1 mark] Alpha: In-house testing by company testers before release
  • [1 mark] Beta: Limited release to potential users for real-world testing
  • [1 mark] Acceptance: Customer tests bespoke software against requirements before sign-off
Answer
  • [1 mark] Normal: "johnsmith" (8 chars, valid)
  • [1 mark] Abnormal: "abc" (too short) or "johnsmith12345" (too long)
  • [1 mark] Boundary: "abcdef" (exactly 6 chars) or "abcdefghijkl" (exactly 12 chars)
Answer
  • [1 mark] Modules might work individually but not communicate correctly together
  • [1 mark] Interfaces between modules (data passing, function calls) need testing when combined
  • [Additional] One module's output might be another module's input, and formats might not match

Program Maintenance

Software requires ongoing maintenance after release to fix errors, improve performance, and adapt to new requirements.

Types of Program Maintenance

Corrective Maintenance

Used to correct any errors that appear during use:

  • Fixing bugs missed during testing
  • Trapping a run-time error that wasn't caught
  • Addressing security vulnerabilities discovered after release
  • Often delivered as patches or updates

Example: Fixing a bug where app crashes when user enters emoji in text field.

Perfective Maintenance

Used to improve performance of a program during its use:

  • Improving speed or efficiency
  • Reducing memory usage
  • Enhancing user interface
  • Adding minor features that improve usability

Example: Optimizing database queries to make search 50% faster.

Adaptive Maintenance

Used to alter a program so it can perform new tasks:

  • Adding support for new hardware or software
  • Complying with new regulations or standards
  • Adding major new features requested by users
  • Adapting to changing business needs

Example: Adding voice command support to a keyboard-only application.

Maintenance Decision Simulation

For each scenario, decide what type of maintenance is needed:

Scenario 1: Users report that the app occasionally crashes when uploading very large files (>2GB).

Scenario 2: New government regulation requires all financial apps to support two-factor authentication.

Scenario 3: Users complain the app takes 10 seconds to load on older phones.

Maintenance Guidelines:

  • Corrective: Fixing bugs, errors, crashes - things that don't work as intended
  • Perfective: Improving performance, speed, efficiency - making what works, work better
  • Adaptive: Adding new features, complying with new requirements - adapting to change
  • Most software spends 60-80% of its lifecycle in maintenance phase

Real-Life Example: Smartphone Operating System

Consider how a smartphone OS (like iOS or Android) demonstrates all three maintenance types:

Corrective

Security Patch: Fixes vulnerability that allows hackers to access photos without permission. Released as urgent update.

Perfective

Performance Update: Reduces battery usage by 20%, makes apps launch 30% faster. Improves existing functionality.

Adaptive

Major Version: Adds support for foldable screens, new gesture controls, and desktop mode. Adapts to new hardware and user needs.

Users receive corrective maintenance as small, frequent patches; perfective maintenance in minor updates; and adaptive maintenance in major annual OS releases.

Check Your Understanding: Program Maintenance

Answer
  • [1 mark] Corrective maintenance - to correct errors that appear during use
  • [1 mark] Perfective maintenance - to improve performance of a program
  • [1 mark] Adaptive maintenance - to alter a program for new tasks required by customer
Answer
  • [1 mark] Corrective: Fix bug where document loses formatting when saved as PDF
  • [1 mark] Perfective: Improve spell check to be 50% faster
  • [1 mark] Adaptive: Add support for voice-to-text dictation feature
Answer
  • [1 mark] Bugs are often found after release that need fixing (corrective)
  • [1 mark] User needs and technology change, requiring software to adapt (adaptive/perfective)
  • [Additional] Software that isn't maintained becomes outdated, insecure, and unusable
Answer
  • [1 mark] Testing happens before release to find errors; maintenance happens after release to fix errors found in live use
  • [1 mark] Both testing and maintenance require test plans and appropriate test data
  • [Additional] Good testing reduces but doesn't eliminate the need for corrective maintenance
Answer
  • [1 mark] A test plan created during development provides a baseline for testing maintenance changes
  • [1 mark] When making maintenance changes, the test plan ensures new code doesn't break existing functionality
  • [Additional] Regression testing (re-testing existing features after changes) relies on a comprehensive test plan

Key Takeaways

  • Fault avoidance starts with good specification and design; fault exposure happens through testing
  • Three main error types: syntax errors (grammar), logic errors (wrong results), runtime errors (crashes during execution)
  • Debugging is finding and fixing errors; IDEs have tools to help
  • Dry-running/walkthrough uses trace tables to manually check algorithms
  • Testing methods: stub testing (dummy modules), black-box (functionality only), white-box (code paths), integration testing (combined modules)
  • Testing levels: alpha (in-house), beta (limited users), acceptance (customer sign-off)
  • Test data should include: normal (valid), abnormal (erroneous), boundary (extreme) values
  • A test plan is needed from the start, covering flow control, validation, loops, data saving, and results
  • Purpose of testing is to discover errors, not prove their absence
  • Program maintenance types: corrective (fix errors), perfective (improve performance), adaptive (add new features)
  • A patch is a small program to fix errors in released software
  • Errors found earlier in development are cheaper to fix than those found after release
  • Testing cannot guarantee a program is fault-free under all circumstances

Question Bank

Marking Scheme & Answer
  • [2 marks] Syntax error: Error in grammar of program. Program won't compile/run. Example: prin("Hello") instead of print("Hello")
  • [2 marks] Logic error: Error in program logic. Program runs but gives wrong results. Example: average = (a+b)/2 for three numbers instead of /3
  • [2 marks] Runtime error: Error during execution. Program crashes. Example: 10 / 0 causes division by zero error
Marking Scheme & Answer
Aspect Black-box Testing White-box Testing
Knowledge of code No knowledge of internal code structure Full knowledge of internal code
Focus Functionality from user perspective Testing all code paths, branches
Tester Independent testers or users Programmers who wrote the code
Basis for tests Requirements and specifications Code structure and logic

Key point: Black-box tests what the software does; white-box tests how it does it.

Marking Scheme & Answer
  • [1 mark] Purpose: To manually check that an algorithm works as intended before coding
  • [1 mark] Process: Step through algorithm line by line with test data
  • [1 mark] Trace table: Table with columns for variables and their values at each step
  • [1 mark] Method: Write down current contents of all variables and conditional values
  • [1 mark] Benefit: Helps find logic errors by showing exactly how values change

Example: For algorithm finding largest of 3 numbers, trace table would show Number1, Number2, Number3 values and which IF conditions are TRUE/FALSE at each step.

Marking Scheme & Answer
  • [1 mark] Modules might work individually but not communicate correctly together
  • [1 mark] Interfaces between modules (data formats, function calls) need testing when combined
  • [1 mark] One module's output might be another's input, and formats/values might not match
  • [Additional] Also tests overall system behavior, not just individual component behavior
Marking Scheme & Answer
  • [1 mark] Normal: 25, 45, 60 (typical valid ages within range)
  • [1 mark] Abnormal: "abc", -5, 0, 150, "13.5" (non-numeric, out of range, wrong type)
  • [1 mark] Boundary: 13, 120, 12, 121 (exact boundaries and just outside)
  • [Additional] Boundary testing checks edge cases where errors often occur
Marking Scheme & Answer
  • [1 mark] Flow of Control: Does user get appropriate choices and correct navigation?
  • [1 mark] Validation of input: Has all data been entered correctly and validated?
  • [1 mark] Loops and decisions: Do they perform correctly under all conditions?
  • [1 mark] Data saving: Is data saved into correct files/databases?
  • [Additional] Also: Does system produce correct results? Is output formatted correctly?
Marking Scheme & Answer
  • [2 marks] Corrective: Fixing errors found during use. Example: Patching security vulnerability that allows unauthorized access
  • [2 marks] Perfective: Improving performance. Example: Optimizing code to reduce memory usage by 30%
  • [2 marks] Adaptive: Adding new functionality. Example: Adding dark mode feature to app that only had light mode

Key distinction: Corrective fixes what's broken, perfective improves what works, adaptive adds new capabilities.

Marking Scheme & Answer
  • [1 mark] A patch is a small program released by developers to run with an existing program
  • [1 mark] Used to correct an error or provide extra functionality after program has been released
  • [Additional] Typically used for corrective maintenance to fix bugs or security issues found in live software
Marking Scheme & Answer
  • [1 mark] Errors found earlier are cheaper and easier to fix (less code to change)
  • [1 mark] Prevents accumulation of errors that become harder to trace later
  • [1 mark] Allows for continuous quality checking and early feedback on design decisions
  • [Additional] Research shows cost of fixing errors increases exponentially the later they're found
Marking Scheme & Answer
  • [1 mark] Stub testing uses dummy modules to simulate modules that aren't yet implemented
  • [1 mark] Allows testing of modular programs before all modules are complete
  • [1 mark] Example: Testing shopping cart module before payment gateway is ready. Stub returns "Payment successful" without actually processing payment.
  • [Additional] Dummy module contains output statement or returns fixed value to indicate call was made