-
Notifications
You must be signed in to change notification settings - Fork 0
Testing and Debugging
Testing and debugging are optional Python-practice topics in the Module Three repository. They do not add another graded deliverable.
You can, however, apply the same thinking to your graded design before any code exists.
A flowchart and pseudocode can be traced by hand.
- Choose an input value.
- Follow the arrows in the flowchart.
- Determine which branch is taken.
- Follow each processing step to the output.
- Repeat the same trace through pseudocode.
- Compare the result with the SRS verification case.
This helps find design errors before they become code errors.
The SRS includes:
- 20 hours — regular-hours case
- 40 hours — boundary case
- 41 hours — first hour above the boundary
- 60 hours — official assignment example
The 60-hour result comes directly from the assignment. The other cases are repository learning checks derived from the same pay rules.
If you implement src/paycheck_calculator.py, run it yourself before using automated tests.
From the repository root:
python3 src/paycheck_calculator.pyEnter one verification value and compare the result with what you expect from the requirements.
Repeat with values that exercise both decision paths and the 40-hour boundary.
The repository provides:
tests/test_paycheck_calculator.py
Run it from the repository root:
python3 tests/test_paycheck_calculator.pyThe test file starts your optional program several times, supplies known input, and checks whether the expected numeric paycheck appears in the output.
You are not expected to understand or edit all of the test code in Module Three.
The official Module Three assignment does not prescribe exact wording or currency formatting for the optional Python implementation.
Therefore, the provided tests look for the correct numeric result rather than one exact sentence.
This is an important testing principle:
Tests should enforce requirements, not preferences that were never requirements.
The program produced a result matching that verification case.
Passing all optional tests does not grade the flowchart or pseudocode and does not submit the assignment.
The program ran, but its output did not match the expected result for a case.
Compare:
- the SRS requirement;
- your flowchart path;
- your pseudocode path; and
- your Python code.
Find the first place they disagree.
The test or program could not complete normally.
For example, a Python syntax error may prevent the program from running.
Read the final part of the error message and correct one problem at a time.
A simple debugging cycle is:
Reproduce → Locate → Correct → Retest
Use the same input that exposed the problem.
Identify the first step where actual behavior differs from the requirement or design.
Change the artifact that is wrong.
- If the design misunderstood the requirement, revise the design.
- If the design is correct but code differs, revise the code.
Run the same case again before moving to a different problem.
The provided test file is course-managed.
If a test fails because your optional program produces the wrong result, correct the program or design. Do not weaken the test merely to make the output turn green.
These are different tools.
The active GitHub workflow checks repository and graded-file completion state. It intentionally does not require the optional Python program to pass.
The local test file evaluates only the optional Python program against the repository verification cases.
Neither system assigns an instructor grade.
Values near a behavior change are especially useful.
The pay rules change around 40 hours, so checking exactly 40 and just above 40 helps reveal errors that an ordinary value might not expose.
Boundary testing is a general programming habit you will use beyond this assignment.
Return to Home or continue to Git and GitHub During the Assignment.