Required assignment path: Start Here → Analyze → Design → Submit

Optional SDLC practice: Construct → Test

Testing checks whether a constructed program behaves as its requirements and design say it should.

For Module Four, testing Python code is optional practice. You do not submit the optional Python program, test file, or test output for grading.

You can also apply testing ideas before code exists by tracing required behaviors through your pseudocode.

This phase produces no graded or submitted Module Four deliverable.

If testing exposes a design problem, correct the graded pseudocode and review it against the rubric again.

Use:

• ../src/hilow_game.py — optional program you constructed;
• your graded ../design/hilow_game.pseudo;
• the official Higher/Lower Game Sample Output;
• the SRS behavior verification cases; and
• test_hilow_game.py — provided optional practice tests.

Do not modify the provided test file to make a failing test pass.

Before automated testing, run your optional program yourself from the repository root. Use the same Bash commands on the CVD, Linux, macOS, and Windows Git Bash:

cd ~/Repos/it140-m4-assignment
python3 src/hilow_game.py

If Python reports a syntax or runtime error, return to the Construct Phase, correct one problem, and run the program again.

Across several runs, check the required behaviors:

• valid lower and upper bounds;
• invalid bounds followed by valid bounds;
• a guess below the selected range;
• a guess above the selected range;
• a valid guess below the target number;
• a valid guess above the target number;
• a correct guess; and
• several guesses before the correct guess.

Because the target number is random, you may need more than one normal run to exercise every path.

Compare actual behavior with the SRS, your pseudocode, and the official Sample Output.

The provided test_hilow_game.py script uses controlled input and a controlled target number so several paths can be checked repeatably.

You have not studied Python testing yet. You are not expected to understand or modify all of the test code.

From the repository root, run:

cd ~/Repos/it140-m4-assignment
python3 tests/test_hilow_game.py

The practice tests intentionally check only selected structural behavior. They do not require one exact set of prompt or output sentences.

They assume you keep the provided randint import in src/hilow_game.py. If you intentionally change that starter structure, use manual testing instead.

A passing test is normally reported as ok, and a fully passing run ends with OK.

That means the optional implementation satisfied the behaviors covered by these repository practice tests.

It does not mean:

• your pseudocode has been graded;
• every rubric criterion is automatically satisfied; or
• the assignment has been submitted.

Read:

1. the failing test name;
2. the behavior that the test expected; and
3. any program output or assertion message shown.

Then compare the same case with:

• the SRS;
• your pseudocode; and
• your Python code.

Find the first place where they stop agreeing.

If the program cannot run normally, the test output may report ERROR or show a Python traceback.

Read the last part of the error information, correct one problem in hilow_game.py, run the program manually, and then rerun the tests.

Do not edit test_hilow_game.py simply to remove a failure.

Testing is iterative:

Test → Find a problem → Correct → Retest

A useful debugging sequence is:

1. reproduce one failing behavior manually;
2. check what the SRS requires;
3. trace the same behavior through your pseudocode;
4. compare those steps with the Python implementation;
5. identify the first mismatch;
6. correct the appropriate artifact; and
7. retest before changing anything else.

If coding reveals a design error, revise the graded pseudocode first and then bring the optional implementation back into alignment.

• The optional program runs without a Python error.
• I checked valid and invalid bound behavior.
• I checked out-of-range guess behavior.
• I checked too-low and too-high valid guesses.
• I checked a correct guess.
• I checked repeated guessing before success.
• My program behavior remains consistent with my pseudocode.
• If a test failed, I corrected the cause rather than modifying the provided test.
• If I changed the graded pseudocode, I reviewed it again against the official rubric.

If you have difficulty:

• Review the SRS behavior verification cases.
• Review Construct for syntax, indentation, and incremental-development guidance.
• See the Module Four Assignment Wiki for supplemental testing and debugging explanations.
• Use GitHub Discussions for questions about optional practice tools.
• Use GitHub Issues to report a technical problem with the provided test file or repository checks.
• Contact your instructor through D2L Brightspace for assignment requirements, grading, or feedback.

Return to Submit Your Assignment. Only design/hilow_game.pseudo is required for the Module Four submission.