The Life Starter
0 of 6 complete0%
Course Library · Lesson 1 of 6
Digital · Guided lesson

Translate a price rule into assertions

About 12 minutes · 4 reading + 8 practice and checks
Time includes reading, practice, and questions. Extra videos or further study are optional.
See this course’s project requirements

A runnable automated test suite for an original parcel-price module with boundary cases, isolated fixtures, failure evidence and a repaired regression.

Keep your working files in your own notebook or software. Save a private description, checklist, and work link in My Proof.

What to include

  • A price assertion table with independent expected values.
  • An executable unit-test record with independent cases.
  • A labeled boundary-test table across both price tiers.
  • A rejection suite with a passing valid boundary comparison.
  • An isolated file test with declared automatic cleanup.
  • A failing-then-passing regression record with source and run instructions.

Review and revise

Use these criteria to check your work and choose what to improve.

  • The implementation or declared simulation follows the supplied contract and retains inspectable original inputs.
  • Normal, boundary and rejected cases are recorded with expected versus observed results.
  • The changed case has a correct explanation and does not rely on hidden state.
  • The project includes source, outputs, instructions and honest tool, privacy and verification limits.
Open the full course project
Want more background?
Before you begin

The idea in everyday life

Fictional fee rule: weight over 0 through 1 kg costs USD 4; over 1 through 5 kg costs USD 7; all other or wrong-type inputs raise ValueError.

The idea

An assertion compares observed behavior with an independently chosen expected result. The expected value should come from the stated rule, not from calling the same implementation again.

Follow along

Translate a price rule into assertions — original worked practice

An assertion compares observed behavior with an independently chosen expected result. The expected value should come from the stated rule, not from calling the same implementation again.

Fictional fee rule: weight over 0 through 1 kg costs USD 4; over 1 through 5 kg costs USD 7; all other or wrong-type inputs raise ValueError.

  1. 1. Step 1

    Calculate expected results for 0.5,1,1.01 and 5.

    You should see: Fees 4,4,7,7.

    This keeps the rule and its observable result together.

  2. 2. Step 2

    Write assertEqual(parcel_fee(1),4).

    You should see: The assertion encodes the inclusive 1 kg boundary.

    This keeps the rule and its observable result together.

  3. 3. Step 3

    Keep the expected rule outside the implementation.

    You should see: A changed bug cannot silently rewrite the test oracle.

    This keeps the rule and its observable result together.

  4. 4. Step 4

    Create a four-row test contract.

    You should see: A price assertion table with independent expected values.

    This keeps the rule and its observable result together.

Now change one thing

Change weight from 1 to 1.2. Enter expected fee USD.

Your work

What to finish

A price assertion table with independent expected values.

Common mistake

Watch for this

Testing an implementation detail while leaving the published weight brackets without assertions.

How can I tell I understand it?

Explain and demonstrate the required distinction: An assertion compares observed behavior with an independently chosen expected result. The expected value should come from the stated rule, not from calling the same implementation again. Show a changed input and the expected result without weakening this contract.

Try 3 questions

Quick knowledge check

Answer all 3 questions. Get at least 2 right and the lesson completes automatically.

Not yet passed

You’ll get an explanation for each answer. Signed in? Your results save to your account.

1Why should expected fee 4 be written independently?
2What fee applies at exactly 1 kg?
3Which input should raise ValueError?
0 of 3 answeredApply the lesson to a short question, then review the explanation.
1
Finish this lesson

Pass the check. We’ll save the progress.

Answer all 3 questions above and get at least 2 right. You can review the explanations and try again.

Go to the knowledge check
Tools, templates, and lesson sources

Tools and templates

Tools open in a new tab so you can keep your place here.

Sources and further reading

Explore the references behind this lesson.

docs.python.org — unittest.html
Source & access notes · checked 2026-10-01

Relevant documented module/API behavior inspected during expansion authoring; actual execution evidence is recorded separately. No grant eligibility is established.

Access: Official page retrieved with the web reader on 2026-10-01. Documentation reading does not certify execution in every native tool or browser.

Reuse: Original local practice files, fictional data, worked examples and questions. Concepts paraphrased and linked; source exercises are not copied.

Report a problem with this lesson

Tell us what went wrong. Please leave out personal information and private project contents.

No sign-in needed.