-
Notifications
You must be signed in to change notification settings - Fork 63
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.
Your two graded files should describe the same planned paycheck calculator:
design/paycheck_calculator.drawiodesign/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.
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:
- Which branch should be taken?
- Which calculations should happen?
- What result should be produced?
Hand tracing helps you find missing steps or inconsistent branches before construction.
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:
- Open your personal
it140-m3-assignmentrepository on GitHub. - Select Actions.
- Open the most recent IT 140 Checks run.
- Open Assignment artifact check.
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.
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.
You can think of design debugging as finding the source of a mismatch.
If a scenario produces the wrong planned result:
- Return to the requirement being checked.
- Follow the flowchart path.
- Follow the pseudocode path.
- Identify where the two designs or the requirement stop agreeing.
- Correct one design problem at a time.
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 the two graded design files:
- Review both against the current Guidelines and Rubric.
- Compare the flowchart and pseudocode with each other.
- Follow the root README's save/commit/push workflow.
- Review the latest Assignment artifact check.
- Submit the two required graded files through D2L Brightspace.
GitHub Actions feedback is formative. Brightspace is the submission and grading system.