Testing an Event Driven Application

Welcome to Testing an Event-Driven Application!

Hello and welcome! In your CCEA AS Level Software Systems Development journey, building your graphical user interface (GUI) and writing event handlers is only half the adventure. The other vital half is proving that your application actually works as intended, handles unexpected user behavior gracefully, and never crashes without warning.

In Unit AS 2: Event Driven Programming, your testing portfolio carries major weight. Whether you feel completely confident or sometimes get overwhelmed by coding terminology, these study notes will guide you step-by-step through designing, executing, and documenting a professional test plan.

Quick Encouragement: Don't worry if testing sounds tedious at first! Once you learn the simple patterns and standard table layouts examiners look for, picking up full marks in this section becomes straightforward and systematic.

1. What is Testing and Why Does It Matter?

In an event-driven program, code does not run in a straight line from top to bottom. Instead, code waits quietly until an event occurs—such as a user clicking a button, typing into a text box, selecting an item from a drop-down list, or closing a form.

Because the user is in complete control of when and how things happen, our testing must be thorough. We test an event-driven system to:

• Verify Requirements: Confirm that every feature detailed in the system analysis phase functions correctly.
• Identify and Eliminate Errors: Catch bugs before a real user encounters them.
• Ensure Robustness: Make sure the system remains stable and does not crash when given unexpected or incorrect input.

Understanding the Three Main Types of Errors

When creating and testing your coursework, you will encounter three distinct types of errors:

1. Syntax Errors: Mistakes in the grammar of the programming language (e.g., a misspelled keyword or missing punctuation). Your development environment will catch these before the program even runs.

2. Runtime Errors: Errors that happen while the program is actively executing (e.g., trying to divide by zero, converting the word "ten" into an integer, or attempting to open a file that does not exist). Runtime errors cause sudden application crashes if not caught by structured error handling.

3. Logic Errors: The code runs smoothly without crashing, but produces the wrong result (e.g., calculating total cost as \( \text{Price} - \text{Discount} \) when it should have been \( \text{Price} \times (1 - \text{Discount}) \)).

Analogy Time: Think of driving a car. A syntax error is trying to start the engine without a key (it just won't start). A runtime error is getting a flat tire on the motorway (the journey stops abruptly). A logic error is driving smoothly for miles in the exact wrong direction (everything seems fine, but the destination is wrong)!

Section Takeaway: Testing ensures our event handlers react properly to user triggers, calculate outputs accurately (preventing logic errors), and protect the system from unexpected crashes (preventing unhandled runtime errors).

2. The Three Pillars of Test Data

To thoroughly test any input field or event in your application, you must choose your test data strategically. The CCEA specification expects you to classify test data into three distinct categories:

A. Normal (Valid) Data

Data that is well within the acceptable rules and boundaries of the system. This represents typical everyday usage (the "happy path").
Example: If a form asks for an applicant's age between \(18\) and \(65\), entering \(25\) or \(40\) is normal data.

B. Boundary / Extreme Data

Data that sits exactly on the outer edges or limits of what is permissible. Many logic errors hide at boundary limits due to subtle coding slips (such as writing \( < \) instead of \( \le \)).
Example: For an age range of \(18\) to \(65\), the boundary values are precisely \(18\) (minimum acceptable) and \(65\) (maximum acceptable).

C. Erroneous / Invalid Data

Data that falls outside the permissible range, contains the wrong data type, or is completely unexpected. The system should reject this data gracefully without crashing.
Example: Entering \(17\) (just below minimum), \(66\) (just above maximum), \(-5\) (negative number), "Twenty" (wrong data type/letters instead of numbers), or leaving the field completely blank.

Memory Trick: Remember the acronym NBE — Normal, Boundary, Erroneous. Every input field in your coursework portfolio should have test cases covering all three!

Section Takeaway: A complete test plan does not just test that things work when the user behaves nicely; it rigorously tests the edges (boundary) and forces the system to deal with mistakes (erroneous).

3. The CCEA Standard Test Plan Structure

In Unit AS 2, you must document your testing inside a structured Test Matrix (Test Table). Examiners look for specific columns to be present and properly filled out.

The Required Table Columns

• Test Number / ID: A unique reference code (e.g., T01, T02, T03).
• Test Description / Purpose: A clear explanation of what component, event handler, or validation rule is being evaluated.
• Test Data / Inputs: The exact values typed in or specific UI actions taken (e.g., Click btnCalculate with txtHours = "45").
• Data Category: Identified as Normal, Boundary, or Erroneous.
• Expected Result / Outcome: The precise behavior that should happen (e.g., "Label lblGrossPay displays £450.00" or "Error message pops up: 'Age must be between 18 and 65'").
• Actual Result / Evidence: What actually occurred when the test was run, referencing an annotated screenshot.
• Remedial Action / Status: Marked as Pass or Fail. If it failed, describe the code fix applied and document the retest.

Example of a Quality Test Plan Entry

Test ID: T04
Test Description: Validate upper boundary value for customer discount percentage (Range: \(0\) to \(20\)).
Test Data / Input: Enter \(20\) into txtDiscount and click btnApplyDiscount.
Data Category: Boundary.
Expected Result: Discount accepted; total updated correctly with \(20\%\) deduction; confirmation message displayed.
Actual Result: As expected. Total reduced by \(20\%\) (See Screenshot Fig 4.2).
Remedial Action / Status: Pass.

Section Takeaway: Every test in your table must be specific. Never write vague expected results like "It should work." Always state the exact message, label text, or screen change expected.

4. Event-Driven Specific Testing Features

Because your AS 2 application is graphical and event-driven, testing involves much more than just calculating numbers. You must test the entire interactive user experience.

1. UI Event Triggering

Event handlers are attached to various user interactions. You must test that each listener triggers its associated code block correctly:

• Button Click Events: Clicking buttons like Submit, Clear, Calculate, or Delete.
• Text Changed Events: Dynamic updates happening in real time as the user types.
• Selection Changed Events: Changing an item in a combo box, list box, or radio button group and verifying that linked fields update immediately.
• Form Lifecycle Events: Form load events (populating initial drop-down lists) and form closing events (prompting "Are you sure you want to exit?").

2. Input Validation vs. Exception Handling

Students often confuse validation with exception handling. They are two separate defensive layers:

Layer 1: Input Validation
Proactive checks written into your code to ensure user input conforms to strict rules before processing. Common checks include:

• Presence Check: Has the user left a mandatory field blank?
• Range Check: Does a number fall within permitted limits (e.g., \(1 \le \text{Quantity} \le 100\))?
• Length Check: Is a password or telephone number the correct number of characters?
• Type Check: Is the entered data of the correct data type (e.g., numbers instead of letters)?
• Format Check: Does an email address or postal code match the required pattern?

Layer 2: Exception Handling (try...catch)
A reactive safety net used to trap unexpected runtime errors during execution so the program doesn't crash.
Example: Wrapping file-reading operations or database connections inside a try...catch block. If a file is missing or locked by another program, the catch block intercepts the error and presents a friendly message box rather than crashing to the desktop.

3. State and Navigation Testing

Testing how your forms communicate and interact:

• Opening secondary forms or dialog boxes from the main menu.
• Checking that modal dialogs prevent accidental background clicks when necessary.
• Testing the Tab Order so users can navigate fields logically using only the keyboard.
• Confirming that disabled buttons (e.g., a greyed-out Save button) become active only when all required data has been validated.

4. Data Persistence Testing

Most AS 2 coursework systems store data in text files, serialized binary files, or database tables. You must test:

• Create / Write: Saving new records and confirming the external storage file actually updates.
• Read / Retrieve: Loading stored data back into list boxes or data grids accurately upon application startup.
• Update & Delete: Modifying or removing existing records without corrupting neighboring data.

Did You Know? In professional software testing, testing external data saving and loading is known as Persistence Testing. If your application loses a customer's data when closed, the application has failed, regardless of how nice the interface looks!

Section Takeaway: Event-driven testing covers the full spectrum: UI events, front-end validation, back-end exception handling (`try...catch`), navigation flows, and persistent file/database storage.

5. Examiner Pitfalls & Common Mistakes to Avoid

Here are the most common traps candidates fall into during AS 2 coursework moderation, along with how you can easily avoid them:

• Pitfall 1: Testing Only the "Happy Path"
The Mistake: Only providing normal, valid data that makes the program look good.
The Fix: Make sure at least one-third of your test plan consists of boundary and erroneous test cases to prove your system is resilient.

• Pitfall 2: Vague Expected Results
The Mistake: Writing "Code works", "Shows message", or "Form loads".
The Fix: Be exact: "Displays error dialog with text: 'Quantity cannot exceed 50'. Focus returns to txtQuantity."

• Pitfall 3: Claiming "Pass" Without Visual Evidence
The Mistake: Typing "Pass" into the table without screenshot proof.
The Fix: Include numbered, annotated screenshots corresponding to every test ID showing the input data and the resulting system output.

• Pitfall 4: Ignoring Event Edge Cases
The Mistake: Forgetting to test rapid double-clicking on submit buttons, closing windows halfway through a process, or clicking 'Cancel' on file dialog boxes.
The Fix: Intentionally try to "break" your interface by clicking controls out of order and verifying that error handling traps these actions safely.

• Pitfall 5: Hiding Bugs Instead of Documenting Remedial Action
The Mistake: Pretending no bugs ever occurred during development.
The Fix: Examiners love to see genuine testing! If a test fails, mark it as Fail, explain the bug, describe the code modification you made to fix it, and show a successful Retest.

6. Summary & Revision Checklist

Before submitting your testing portfolio for Unit AS 2, review this quick checklist to ensure maximum marks:

• Have you tested all major event handlers (button clicks, form loads, selection changes)?
• Does your test plan clearly label data as Normal, Boundary, or Erroneous?
• Are validation checks (presence, range, type, length, format) tested with invalid data?
• Are external file/database operations tested with `try...catch` safety nets in place?
• Is every test backed up by clear, annotated screenshot evidence cross-referenced to its Test ID?
• Are failed tests documented alongside their remedial code fixes and retests?