Welcome to Testing an Event Driven Application
Welcome to one of the most vital chapters in your CCEA AS 2: Event Driven Programming journey! Whether you are building a full graphical user interface (GUI) application for your coursework portfolio or preparing for exam-style scenarios, understanding how to systematically test your code is essential.
Don't worry if software testing sounds daunting at first. In this guide, we will break down testing into clear, manageable steps. You will learn how event-driven systems work, how to pick the right test data, how to create a proper test plan according to CCEA standards, and how to avoid the common traps students often fall into.
1. Understanding Event-Driven Applications and Testing
What Makes Event-Driven Applications Unique?
In traditional procedural programs, code executes in a fixed sequence from top to bottom. In contrast, an event-driven application sits idle waiting for something to happen. It executes specific code blocks (called event handlers or listeners) in response to actions such as:
• User actions: Clicking a button, typing into a text box, moving the mouse, or selecting an item from a combo box.
• System triggers: A timer tick event, a background file loading, or a database read completing.
Everyday Analogy: Think of a microwave oven. It does not automatically run all its programs from start to finish. It sits waiting for you to press buttons (events). If you press "Start" without entering a time, it should alert you rather than short-circuiting. Your graphical software must behave just as reliably!
Why is Testing Event-Driven Software Crucial?
Because the user can click buttons in any order, enter any unexpected data, or leave fields blank, testing an event-driven system involves checking:
• User Interface (UI) State Transitions: Do buttons enable or disable at the right time?
• Business Logic: Do internal calculations and algorithms produce correct outputs?
• Data Validation: Does the program check that data is present, in range, and of the right type before processing?
• Exception Handling: Are runtime errors trapped using structured try...catch blocks so the program displays a helpful message rather than crashing?
Quick Key Takeaway: Testing an event-driven app is not just about checking calculations; it is about ensuring the entire interface responds safely and predictably to any event or user action.
2. The Three Categories of Test Data
Whenever you test form inputs, calculations, or validation routines, CCEA expects you to select and justify data from three distinct categories.
1. Normal (Valid) Data
• Definition: Data that is completely acceptable and falls well within the expected range and format.
• Purpose: Confirms that standard, typical inputs produce the expected outputs and regular business logic works properly.
• Example: If an input field asks for an employee's age between \(18\) and \(65\), entering \(25\) or \(40\) is normal data.
2. Boundary / Extreme Data
• Definition: Data at the exact outer limits of acceptability (the minimum and maximum acceptable values).
• Purpose: Tests edge cases to ensure relational operators (such as \(<\) versus \(\le\), or \(>\) versus \(\ge\)) do not cause "off-by-one" calculation or logic errors.
• Example: For an age range of \(18\) to \(65\), the boundary values are exactly \(18\) (minimum boundary) and \(65\) (maximum boundary).
3. Erroneous / Abnormal (Invalid) Data
• Definition: Data that is outside the acceptable range, of the incorrect data type, or completely missing.
• Purpose: Confirms that validation rules and structured exception handlers (try...catch) intercept bad inputs gracefully and output clear error messages without crashing the application.
• Example: Entering \(17\) (too low), \(66\) (too high), "twenty" (incorrect data type), or leaving the box blank (null/empty string).
Memory Trick: Remember the acronym N-B-E — Nice (Normal/valid), Border (Boundary/limits), Error (Erroneous/invalid).
Quick Key Takeaway: A complete test set must always include all three: Normal, Boundary, and Erroneous data. Testing only valid data leaves your application open to unexpected crashes.
3. Levels and Types of Testing in the AS 2 Lifecycle
Testing takes place at different levels throughout the development of your software solution:
A. Unit Testing
• Testing individual methods, algorithms, and event handlers in isolation.
• Example: Verifying that a standalone method calculating total pay, such as \(40 \times 15.00 = 600.00\), works correctly before connecting it to a GUI button click event.
B. Integration Testing
• Testing that different modules and layers work together seamlessly.
• In AS 2, this involves checking data flow between the UI event handlers, custom object-oriented business classes, and data persistence (such as reading from or writing to text files and object streams).
C. Validation Testing
• Checking user input against validation rules before saving or processing it.
• Common checks include presence checks (not blank), range checks (e.g., between \(1\) and \(100\)), type checks (numeric vs. text), and length/format checks.
D. System / Functional Acceptance Testing
• End-to-end testing of the complete, fully assembled GUI application.
• Demonstrates that all user requirements and design specifications set out at the start of the project are fully satisfied.
Quick Key Takeaway: Start small with Unit Testing, connect parts together with Integration Testing, guard inputs with Validation Testing, and finish with full System Testing.
4. The CCEA Standard Test Plan
For CCEA AS 2, you must document your testing inside a formal Test Plan Table. Each test case must be clear, rigorous, and accompanied by screenshot evidence.
Required Test Plan Columns
1. Test ID: A unique reference identifier (e.g., TC01, TC02).
2. Test Description / Purpose: A clear, precise statement of what event, calculation, or validation rule is being tested.
3. Test Data Used & Category: The exact input values used, clearly labeled as Normal, Boundary, or Erroneous.
4. Expected Result: Exactly what the system should do (e.g., update a label, show a specific error dialogue, write to file).
5. Actual Result: What actually happened when you executed the test.
6. Pass / Fail Status: A clear record of whether the actual result matched the expected result.
7. Evidence Reference / Action Taken: A direct reference to your dated screenshot evidence (e.g., Screenshot Appendix Fig 2.1) or a note describing the code correction and re-test if a bug was found.
Example Test Plan Walkthrough (Booking Form Scenario)
Scenario: A text box allows users to input the number of tickets to book, valid from \(1\) to \(10\).
Test Case 1 (Normal Data):
• Test ID: TC01
• Test Description: Verify that entering valid ticket quantity calculates correct subtotal.
• Test Data: \(5\) (Normal Data)
• Expected Result: Subtotal updates to show price for \(5\) tickets; status label shows "Tickets added".
• Actual Result: Subtotal updated correctly; status label updated.
• Status: Pass
• Evidence / Action: See Screenshot 1a.
Test Case 2 (Boundary Data):
• Test ID: TC02
• Test Description: Verify minimum and maximum acceptable ticket limits.
• Test Data: \(1\) and \(10\) (Boundary Data)
• Expected Result: Both inputs accepted; correct calculation displayed.
• Actual Result: Both inputs accepted; calculations correct.
• Status: Pass
• Evidence / Action: See Screenshots 1b and 1c.
Test Case 3 (Erroneous Data):
• Test ID: TC03
• Test Description: Verify error trapping when a non-numeric string is entered.
• Test Data: "ten" (Erroneous Data)
• Expected Result: Validation message box displayed: "Please enter a valid whole number between 1 and 10"; no crash occurs.
• Actual Result: Message box displayed as expected; application remained stable.
• Status: Pass
• Evidence / Action: See Screenshot 1d.
Quick Key Takeaway: A top-mark test plan is precise and thorough. Anyone reading your test plan should be able to recreate your exact test step-by-step.
5. Common Pitfalls and Examiner-Reported Errors
Avoid these common mistakes highlighted in CCEA assessment reports:
• Vague Test Descriptions: Writing "Test the button" or "Check form works" will lose marks. Always be explicit: "Verify that clicking 'Calculate' with hours = 40 and hourly rate = 15 updates lblTotalPay to 600.00".
• Confusing Boundary and Erroneous Data: Remember, boundary data is valid (the exact edge of what is allowed). For a range of \(1\) to \(100\), \(1\) and \(100\) are boundary values; \(0\) and \(101\) are erroneous values.
• Uncaught Runtime Exceptions: Forgetting to test how your form reacts to invalid formats (like typing letters into a price field). If your program throws an unhandled FormatException and crashes, you need a try...catch block to handle the error.
• Missing Screenshot Evidence: Marking a test as "Pass" without including a clear, dated, annotated screenshot showing the actual UI output or error message.
• Treating Testing as a "One-Time" Final Task: Testing should be iterative. When a test fails, document the bug, explain the code modification you made, and record the successful re-test.
Chapter Summary & Quick Review Checklist
Before submitting your coursework portfolio or sitting your examination, review this checklist:
• Event-Driven Awareness: Can you explain how UI state changes, user events (clicks/keypresses), and system events require careful input validation and exception handling?
• Test Data Variety: Have you included Normal, Boundary, and Erroneous test data for every major input?
• Testing Levels: Do you understand the difference between Unit, Integration, Validation, and System testing?
• CCEA Table Standard: Does your test plan include Test ID, Description, Data & Category, Expected Result, Actual Result, Pass/Fail Status, and Evidence Reference?
• Clear Evidence: Do you have annotated screenshots demonstrating every actual result?