Skip to content

Testing and Debugging

mike-snhu edited this page Sep 13, 2026 · 5 revisions

Testing and Debugging

Module Three is primarily a design assignment. The graded work is the flowchart and pseudocode, not the optional Python program.

Testing still matters because you can review whether your design is complete, internally consistent, and ready to translate into code.

Use the repository README and Design README for the current required checks. This page explains how manual review, GitHub Actions, and optional Python testing differ.

Review the Two Graded Designs Together

Your two graded files should describe the same planned paycheck calculator:

  • design/paycheck_calculator.drawio
  • design/paycheck_calculator.pseudo

Compare them requirement by requirement.

For example, ask whether both representations show the same:

  • Inputs
  • Regular-pay calculation
  • Overtime decision and calculation
  • Final output
  • Overall sequence and branching

If the flowchart and pseudocode disagree, decide which one does not match the requirements and correct that design.

Trace a Scenario by Hand

A useful design test is to follow example input through the planned logic without writing Python.

Use the current SRS and assignment instructions. For each scenario, ask:

  1. Which branch should be taken?
  2. Which calculations should happen?
  3. What result should be produced?

Hand tracing helps you find missing steps or inconsistent branches before construction.

GitHub Actions: Assignment Artifact Check

Each push to your personal repository runs IT 140 Checks.

The student-facing Module Three check is:

Assignment artifact check

The current automated check can verify basic repository conditions such as:

  • Required course files remain present.
  • Committed changes are limited to student-editable files.
  • After graded work begins, both graded design files have changed from the starter state.
  • The Draw.io file remains readable XML.
  • The pseudocode retains required basic structure and no longer contains starter TODO: prompts.

To review feedback:

  1. Open your personal it140-m3-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 flowchart satisfies every rubric criterion.
  • The pseudocode logic is fully correct.
  • Both designs describe exactly the same solution.
  • The assignment has been submitted.

Manual requirement-based review is still necessary.

Optional Construct and Test Practice

After the graded designs are complete, you may optionally construct:

src/paycheck_calculator.py

and use the provided testing practice.

That optional Python work can help you discover whether your design was clear enough to implement.

If Python construction reveals a design problem, return to the design rather than forcing the code to work around an unclear plan.

Debugging a Design

You can think of design debugging as finding the source of a mismatch.

If a scenario produces the wrong planned result:

  1. Return to the requirement being checked.
  2. Follow the flowchart path.
  3. Follow the pseudocode path.
  4. Identify where the two designs or the requirement stop agreeing.
  5. Correct one design problem at a time.

If the Automated Check Appears Broken

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

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

See Assignment Problems and Support.

Before Submitting

Before submitting the two graded design files:

  1. Review both against the current Guidelines and Rubric.
  2. Compare the flowchart and pseudocode with each other.
  3. Follow the root README's save/commit/push workflow.
  4. Review the latest Assignment artifact check.
  5. Submit the two required graded files through D2L Brightspace.

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

Clone this wiki locally