Testing and Debugging

Testing and Debugging

Testing and debugging are related, but they are not the same activity.

Testing checks whether software behaves as expected.

Debugging is the process of finding and correcting the cause of a problem.

Use the Test README for the required Module Two steps. This page explains the testing and debugging ideas you encounter during the assignment.

Test-phase instructions:

https://github.com/GC-STEM/it140-m2-assignment/blob/main/Part-A/tests/README.md

You Have Been Testing Throughout Part A

Testing does not begin only after you finish writing the program.

During Part A:

• In Design, you follow a provided test case through the planned solution.
• In Construct, you run the program after small changes.
• In Test, you check the completed program against requirements and expected results.

This progression helps you find problems closer to the point where they were introduced.

Expected Result Versus Actual Result

A test compares:

Expected result — what should happen
Actual result — what actually happened

If those results match, the test passes.

If they do not match, you have information that can help you locate a problem.

A failed test does not automatically tell you which line of code to change. It tells you which behavior needs investigation.

Manual Testing

Manual testing means you run the program yourself and enter test data.

For the name_age program, manual testing lets you observe:

• The prompts
• The values you type
• Whether the program completes
• The displayed result
• Whether the output format matches the requirement

Before using other feedback tools, make sure the program can run normally.

Acceptance Tests

An acceptance test checks whether software provides required behavior.

The Module Two SRS contains the shared acceptance test cases for the name_age program.

SRS:

https://github.com/GC-STEM/it140-m2-assignment/blob/main/Part-A/analysis/name_age_srs.md

The cases include both typical and edge-case values.

When a test fails, compare the result with the corresponding acceptance case and requirement before changing code.

Edge Cases

An edge case uses an unusual, extreme, or boundary value that can reveal assumptions in a solution.

The assignment asks you to identify provided edge cases during Analyze.

You do not need to invent additional requirements for handling values that the SRS does not require.

A useful rule is:

Test the behavior the requirements specify. Do not silently create new requirements while testing.

Incremental Testing

During Construct, the repository recommends changing a small amount and running the program again.

This approach is useful because:

1. The program worked before your recent change.
2. You make one small change.
3. A new problem appears.
4. The recent change becomes a likely place to inspect first.

This does not prove the recent line is the only possible cause, but it narrows the search.

The Instant Feedback Tool

The Test README identifies the current 2-3 Instant Feedback Tool in D2L Brightspace as the official course feedback method for this assignment.

Use the current Test README and D2L instructions for:

• Where to open the tool
• How to provide your program
• How to interpret course-specific feedback
• Any current technical details

Feedback from the tool does not submit your assignment for grading.

Return to D2L Brightspace and follow the Module Two What to Submit instructions when your work is complete.

The Provided Automated Tests

The repository also includes:

Part-A/tests/test_name_age.py

The local automated tests are optional.

You have not studied Python testing yet, so you are not expected to understand or modify the test file.

The test program:

1. Runs your name_age.py program with known input.
2. Captures what your program produces.
3. Compares the result with the expected result.
4. Reports whether each acceptance test passed.

Use the current command in the Test README:

https://github.com/GC-STEM/it140-m2-assignment/blob/main/Part-A/tests/README.md

Do not copy an older command from notes, screenshots, or another repository.

Reading Local Test Results

ok

When an individual automated test passes, its result ends with:

... ok

That test's actual result matched what the test expected.

OK

When the test runner reports:

OK

after running all provided tests, your program passed those local acceptance tests.

This does not guarantee a particular assignment grade. The grading rubric includes requirements beyond simply passing the local test cases.

FAIL

A result of:

FAIL

means the test completed, but your program's behavior did not match the expected result.

A useful response is:

1. Identify which test failed.
2. Read the failure information.
3. Find the matching acceptance test in the SRS.
4. Identify the requirement being checked.
5. Inspect the corresponding part of name_age.py.
6. Correct one problem.
7. Run the program again.
8. Rerun the tests.

Do not edit the provided test to make your program appear to pass.

ERROR

A result of:

ERROR

means the automated test could not complete normally.

This can happen for reasons different from an ordinary wrong answer.

Follow the Test README's current troubleshooting checks before changing files.

Python Errors

A Python error can stop the program before it produces the required result.

The exact message matters.

Read the bottom portion of the error output and look for information such as:

• The file involved
• A line number
• The type of error
• A short explanation

Then compare that location with the code you most recently changed.

Syntax Errors

A syntax error means Python cannot interpret the code as valid Python syntax.

Common beginner causes include:

• Unmatched quotation marks
• Unmatched parentheses
• Incorrect indentation
• Missing punctuation required by the statement
• Typing a Python statement incorrectly

Use the recent change, the error message, and VS Code indicators to locate the problem.

Runtime Errors

A runtime error occurs after Python starts running the program.

For example, a program may try to perform an operation using a value in a form that does not support that operation.

Read the error information and compare the failed operation with the type of data your program is using.

Incorrect Output

A program can run without a Python error and still be incorrect.

Examples include:

• Wrong calculation
• Wrong value displayed
• Missing required text
• Extra text
• Incorrect output format

This is why testing must compare program behavior with the SRS rather than only checking that Python runs.

Use the Problems Panel Carefully

VS Code can identify some issues in the Problems panel.

It can help you locate syntax, formatting, or code-quality concerns, but it is not a replacement for the assignment requirements or program tests.

When you see a problem:

1. Read the message.
2. Identify the file and line.
3. Decide whether it relates to code you are allowed to change.
4. Use the assignment instructions and relevant zyBooks material before making a change.

The Module Two starter file contains provided structure that you should not rewrite merely because it is unfamiliar.

Debug One Problem at a Time

When several things appear wrong, avoid changing many lines at once.

Use this loop:

Test → Find one problem → Correct it → Test again

This helps you learn which change affected the result.

If the program becomes more confusing after several edits, use Git and GitHub history or the repository recovery instructions rather than randomly deleting files.

See Git and GitHub During the Assignment.

Do Not Debug by Changing the Requirement

If your result does not match the SRS, do not change the expected result to fit your code.

Return through the chain:

Requirement → Design → Code → Test

The SRS tells you what is expected.

The provided design helps show the planned solution.

Your code should implement that plan.

The tests check the result.

When to Ask for Help

Ask for help when:

• You cannot interpret an error after reviewing the relevant instructions.
• You cannot get name_age.py to run.
• A provided test reports an unexpected technical error.
• A course-provided file appears missing or damaged.
• You are unsure whether the problem is your code or the course environment.

Before asking, collect:

• What you were trying to do
• What you expected
• What happened
• The exact error message or test result
• The file and line involved, if shown
• The troubleshooting steps you already tried

Do not publicly post passwords, tokens, private information, or complete solutions to graded work.

See Assignment Problems and Support for the correct support channel.