Video Game Design and Coding · PLECK lesson

PLECK lesson 136 · suggested week 28, day 1

Write tests before a small rule change

Objective. Predict behavior and encode it as assertions.

Godot Engine Standard desktop editor 4.7.2-stable, GDScript (Godot 4), Compatibility renderer. Headless Godot 4.7.2.stable.official.ed1daf0bf passed 106 assertions on the supplied scaffolds, including malformed JSON saves. Audio used the Dummy driver and a synthetic WAV, not a speaker. The visual editor, browser export, and signed-in submission were not tested. The desk still does not run a student's own upload.

About 55 minutes. The due date is chosen by a parent.

Pure functions, boundary cases, error reading and focused repair

Suggested pace: Recall and predict 5 min; Read instruction and scaffold 12 min; Build or design the assigned artifact 25 min; Run acceptance tests 8 min; Explain and checkpoint 5 min.

Materials: Godot Standard 4.7.2 desktop editor (GDScript, Compatibility renderer), Local course folder and prior checkpoint, No paid assets or public account required.

Comes after VGC-L135.

Use C-TESTS to see a small pure-function harness. The bounded_score rule adds a change and clamps the result to zero through 999. Write a new rule for a combo bonus: one through three deliveries earn two points each, while four or more earn an additional five-point bonus. Define zero and negative inputs explicitly before coding. Assertions compare actual and expected results. Start with a failing test in a duplicate or new lab, implement the function, then run all tests.

Worked example

A capacity function tested at below-minimum, middle and above-maximum inputs is easier to trust than one demonstrated only at a normal value. Scaffold C-TESTS — A tiny pure-function test harness Setup: Attach to Node TestLab. If using command line, create a separate SceneTree harness rather than running this Node script with --script. Run current TestLab scene in editor; assert reports a failed condition in Debugger. No external test framework or package is needed. ```gdscript extends Node func bounded_score(old_score: int, change: int) -> int: return clampi(old_score + change, 0, 999) func _ready() -> void: assert(bounded_score(10, 2) == 12) assert(bounded_score(0, -3) == 0) assert(bounded_score(998, 9) == 999) print("3 score checks passed") ```

A tiny pure-function test harness

GDScript (Godot 4, not Scratch, Python, JavaScript or C#). Scaffold C-TESTS. Copy starts from this text. The desk does not run it.

Scene and node setup

Attach to Node TestLab. If using command line, create a separate SceneTree harness rather than running this Node script with --script. Run current TestLab scene in editor; assert reports a failed condition in Debugger. No external test framework or package is needed.

extends Node
func bounded_score(old_score: int, change: int) -> int:
    return clampi(old_score + change, 0, 999)
func _ready() -> void:
    assert(bounded_score(10, 2) == 12)
    assert(bounded_score(0, -3) == 0)
    assert(bounded_score(998, 9) == 999)
    print("3 score checks passed")

Checks to run in the editor

Native Godot 4.7.2.stable.official.ed1daf0bf headless compile and representative node-tree/runtime tests passed; see native-qa-results.json. Visual UI, audible output, exports and website submission still need separate checks.

Write tests before a small rule change — evidence task

  1. 1. Write expected results for counts -1,0,1,3,4 and 6.
  2. 2. Implement the rule so invalid negative counts return zero.

Deliverable. Combo-rule lab and six assertions.

Acceptance checks

Understanding question. Why is the first bonus-boundary test count 4 important?

Include a downloadable project ZIP with project.godot, .tscn, .gd and original asset files when code changes. A private, teacher-accessible download link to that ZIP is equivalent. Screenshots or a playthrough do not replace editable source.

If this is still shaky. Use C-TESTS and one ordinary plus two boundary cases. Keep a known-good snapshot before injecting faults. Start with the first assigned task and re-run its acceptance test before adding the remaining feature.

Optional extra. Add a property that should hold for many inputs and test a small finite range. Document one changed parameter, your prediction, and the observed effect; optional, not required for completion.

Name ____________________ Date ____________________