Testing and Debugging

Testing and Debugging

Testing appears in both coding checkpoints, but the scope changes.

Module Six

Test the small movement prototype against the provided three-room scenario.

Focus on:

• Valid movement
• Invalid direction
• Invalid command
• exit
• Loop termination

Because the data is fixed, you can repeat the same command sequence while isolating defects.

Module Seven

The final game is student-specific, so use your Project One map as a test model.

Plan cases for:

• Valid and invalid movement
• Valid and invalid item requests
• Inventory updates
• Status/function output
• Complete winning path
• Complete losing path

Use Known Paths

Do not rely only on casual exploration. Write down a path that should win and a path that should lose, then replay them after meaningful code changes.

Debug One Problem at a Time

Use this cycle:

Reproduce → Locate → Change one thing → Retest

If the first incorrect behavior occurs before the visible failure, fix that earlier step rather than patching only the final symptom.

Design Defects vs Code Defects

Sometimes testing reveals that the implementation matches the pseudocode but the pseudocode itself is wrong or incomplete.

In that case, update the design first, then make the code match the corrected design. That preserves SDLC traceability.

Automated Repository Checks

GitHub Actions checks basic completion and structure. It cannot know whether every student's unique map is winnable or whether every final-game path is correct.

Manual requirement-based testing remains necessary.