Testing and Debugging

Testing and Debugging

Module Four is primarily a pseudocode design assignment. The graded file is:

design/hilow_game.pseudo

Testing the design means checking whether the planned sequence, decisions, validation, and loops match the current assignment requirements and sample behavior.

Use the repository README and Design README for required steps. This page explains manual design review, the GitHub Actions artifact check, and optional Python testing.

Trace the Pseudocode by Hand

Use sample scenarios to follow your pseudocode from beginning to end.

Ask questions such as:

• Are the lower and upper bounds obtained in the correct order?
• Does validation repeat when the bounds are invalid?
• Does the guessing loop continue while the game is not finished?
• Does each guess lead to the correct decision branch?
• Does the program stop at the correct time?

Compare your design with the current Guidelines and Rubric and official sample output.

GitHub Actions: Assignment Artifact Check

Each push to your personal repository runs IT 140 Checks.

The student-facing Module Four job is:

Assignment artifact check

The check can verify basic repository/file conditions such as whether required course files remain present and whether the graded pseudocode has moved beyond its starter state while retaining expected basic structure.

To review feedback:

1. Open your personal it140-m4-assignment repository on GitHub.
2. Select Actions.
3. Open the most recent IT 140 Checks run.
4. Open Assignment artifact check.

What a Green Check Means

A green result means the automated checks passed for the repository state they inspect.

It does not mean the pseudocode satisfies every rubric criterion, contains correct logic for every path, or has been submitted for grading.

Manual requirement-based review is still required.

Optional Python Construction and Testing

After the graded pseudocode is complete, you may optionally translate your design into:

src/hilow_game.py

Optional construction can help you discover missing or unclear design steps.

If the Python program is difficult to implement because the pseudocode is unclear, return to the design rather than adding unexplained logic only in the code.

Optional tests can help you compare program behavior with expected scenarios, but they do not change the one-file graded Module Four submission.

Debugging the Design

If a hand trace or optional program produces the wrong planned result:

1. Identify the requirement or sample behavior involved.
2. Follow the pseudocode one step at a time.
3. Locate the first point where the planned path differs from the requirement.
4. Correct one design problem at a time.
5. Trace the scenario again.

If the Automated Check Appears Broken

If the check reports a problem caused by your editable file, use the feedback to revise it.

If the workflow appears unable to run because of a missing provided file, GitHub Actions configuration problem, or another technical course-repository issue, report it through GitHub Issues.

See Assignment Problems and Support.

Before Submitting

Before submitting the graded pseudocode:

1. Review it against the current Guidelines and Rubric.
2. Trace important sample paths by hand.
3. Follow the root README's save/commit/push workflow.
4. Review the latest Assignment artifact check.
5. Submit the required pseudocode file in D2L Brightspace.

GitHub Actions feedback is formative. Brightspace is the submission and grading system.