Skip to content

Testing and Debugging

mike-snhu edited this page Aug 25, 2026 · 2 revisions

Testing and Debugging

Testing ideas are useful in Module Four even though Python construction and testing are optional.

You can first trace the pseudocode by hand, then use manual and automated tests if you complete the optional Python practice.

Design Verification Comes First

Before writing Python, choose a required behavior and trace your pseudocode.

Useful cases include:

  • invalid bounds followed by valid bounds;
  • an out-of-range guess followed by a valid guess;
  • a too-low valid guess;
  • a too-high valid guess; and
  • a correct guess that ends the game.

Follow each statement, branch, and loop literally.

If the design does not describe what should happen, correct the pseudocode before coding.

Manual Testing of the Optional Program

If you complete src/hilow_game.py, run it from the repository root:

python3 src/hilow_game.py

Use several runs because the target number is random.

Compare the program with:

  1. the official Guidelines and Rubric;
  2. the Higher/Lower Game Sample Output;
  3. the SRS; and
  4. your pseudocode.

Optional Automated Practice Tests

The repository includes tests/test_hilow_game.py.

Run:

python3 tests/test_hilow_game.py

The test code uses controlled input and a controlled target number to make selected paths repeatable.

You are not expected to understand or modify all of the testing code yet.

The tests are optional practice and are not part of the graded Module Four submission.

What PASS Means

A passing optional test means the Python implementation satisfied the specific behavior checked by that test.

It does not mean:

  • the pseudocode automatically earns full rubric credit;
  • every possible behavior was tested; or
  • the assignment was submitted.

When a Test Fails

Do not immediately change random code until the test turns green.

Instead compare, in order:

  1. Requirement: What should happen?
  2. Pseudocode: What did you design?
  3. Python: What did you implement?
  4. Observed behavior: What actually happened?

Find the first disagreement.

Debug One Problem at a Time

A useful cycle is:

Test → Find the first mismatch → Correct → Retest

If the pseudocode is wrong, revise the graded design first. Then update the optional code to match it.

If the code is wrong but the pseudocode is correct, keep the design and correct the implementation.

Common Loop Problems

When repeated behavior is wrong, check:

  • Is the loop condition the one you intended?
  • Can something inside the loop change the condition?
  • Is new input obtained when the player needs another attempt?
  • Does an incorrect guess continue the game?
  • Does a correct guess allow the guessing loop to stop?
  • Is validation occurring at the right point?

Do Not Modify Provided Tests to Hide a Problem

The provided tests are course-managed practice tools.

If a test exposes a mismatch, correct the design or optional program as appropriate. Editing the test merely to remove the failure defeats the purpose of testing.

Assignment Checks vs. Optional Python Tests

These are different tools:

  • Assignment Checks verify repository integrity and basic completion state of the graded pseudocode.
  • Optional Python tests exercise selected behaviors in the optional program.

A student does not need to complete the optional Python program to receive a green Assignment Check.

Return to Home or continue to Git and GitHub During the Assignment.

Clone this wiki locally