<!-- Generated from applied-computing-au vic/unit3-4/sat/C08-2026/C08-Reference-Godot by port-reference-godot-to-wiki.py — do not hand-edit; re-run the port. -->
# Testing Tables and Corrections

*The testing table is the artefact the whole C8-1 rubric reads from: one row per test, and for every failed test, what you did about it.*

**Definition.** A testing table documents each test case: the exact input you ran, the output you **expected**, the output you **actually** got, and — when the two disagree — the **corrective action** you took. Expected-vs-actual across a range of data is the 7–8 discriminator; a complete list of corrective actions for every failed test is the 9–10 one.

## The structure

| Column | What goes in it |
|---|---|
| Test Case ID | TC001, TC002, … |
| Test Description | what this row proves, in one phrase |
| Input Data | the exact value(s) entered |
| Expected Output | the specific output — never just "works" |
| Actual Output | what really happened, even when it matches |
| Pass/Fail | one word |
| Error Type | S / L / R / V (below) |
| Corrective Action / Notes | for every Fail: what you changed, and the re-run result |

**Error types:** **S**yntax · **L**ogic · **R**un-time · **V**alidation

## A worked slice

| Test ID | Description | Input | Expected | Actual | Result | Corrective action |
|---|---|---|---|---|---|---|
| TC001 | Valid login | saleh / OoeiO9! | Access granted, menu screen | Access granted, menu screen | Pass | — |
| TC002 | Wrong password | saleh / saleh | Error message | **Access granted!** | Fail | Login branch never compared the password — added the check; re-run: error shows ✅ |
| TC004 | Update existing profile | (edit form) | Profile updated, back to menu | Profile did not update | Fail | Save wrote to a copy, not the record — fixed reference; re-run: Pass ✅ |

The Fail rows are where the marks live: *fault → fix → re-run result*, written next to the row. That same fix cycle, performed live, is what your screen recording must show.

## Rules that keep the table honest

- **Write Expected before you run.** An expected output copied from the actual output tests nothing.
- **Never delete a failed row.** The fail plus its corrective action *is* the evidence — a table of green Passes scores lower than one showing real fixes.
- **Cover the range:** valid, boundary, invalid, wrong, absent — see [Types of Test Data](/sd/C08/Types%20of%20Test%20Data).
- **At least one row per validation rule** in your code: the empty field, the out-of-range value, the wrong type — with the input that should trigger it.

## Going further — automated tests

A unit test is a testing-table row written as code, so it re-runs itself after every change (in Godot: the **GUT** addon). A passing automated suite is strong "all modules function correctly" evidence for 9–10 — but the documented table stays the required artefact.

The blank template is in your class repo: `S-C08/C081-Alpha-Testing-Plan-Template.md`.