Compare Expected and Actual Results

A plausible result is not evidence of correctness

Continue the order calculation: each item costs 20 units, packing costs 5 per order, and quantity must be a positive whole number. There are no discounts or other charges.

Someone writes this expression for the total:

const unitPrice = 20;
const quantity = 1;
const packingCharge = 5;
const total = (unitPrice + packingCharge) * quantity;
console.log("Order total:", total);

It prints 25. That matches the expected total for one item.

Pause and write: Has the program been proven correct? Choose a second quantity that would challenge its interpretation of packing.

Build expectations independently

Calculate these cases from the written rule, not from the proposed expression:

For two items, the proposed program produces 50. One successful example hid the fact that packing was being charged per item.

A test case describes the inputs and expected behavior. The actual result is what execution produces. A useful test compares the two rather than treating the program's answer as its own proof.

Investigate instead of changing things at random

1. Reproduce the mismatch with quantity 2.
2. Write expected 45 and actual 50.
3. Inspect the calculation: the parentheses add packing before multiplying.
4. Form a hypothesis: packing is counted twice.
5. Compare the rule with separate steps: subtotal first, then packing.
6. Change that calculation and rerun all three cases.

The corrected core is:

const subtotal = unitPrice * quantity;
const total = subtotal + packingCharge;
console.log("Expected:", 45);
console.log("Actual:", total);

This fragment replaces the original total calculation for quantity 2. Keep the input declarations. Start a fresh console context before running the revised program.

Make a mismatch visible

JavaScript offers strict equality, written ===. It compares values without converting one type into another. For the small whole-number examples here, it lets us compare the calculated amount with an expected amount.

const expectedTotal = 45;
console.log("Matches expectation:", total === expectedTotal);
console.assert(total === expectedTotal, "Expected an order total of 45");

A comparison produces a Boolean value: true or false. console.assert reports an assertion failure when its condition is false. A successful assertion normally produces no failure message. It does not stop the program or replace a full test runner.

Remember: = assigns, while === compares. A test can also be wrong if its expected value comes from an incorrect interpretation.

Execution error or wrong behavior?

An unfinished statement can cause a syntax error. A misspelled variable can cause a reference error. A valid expression implementing the wrong charge is a logic error: the program runs, but violates the rule.

Read the error message and identify the relevant statement before editing. For a logic error, trace the intermediate values against the expected steps. A debugger will later help automate this inspection; careful reasoning comes first.

Guided exercise: describe the boundary of this version

What should happen with quantity 0, -1 or 1.5?

Correction

All violate the exercise's positive-whole-number rule. The current program has no validation and will still calculate a number. That is a limitation, not evidence that these inputs are acceptable. Record the required behavior as "reject the order with a clear explanation." We will implement validation after learning conditions.

Use only valid, manually supplied inputs in this version. Do not present this exercise as a ready-to-use checkout. Monetary rounding, real input handling and other business rules require additional decisions.

Independent lab: a rule changes

The owner replaces the packing rule with a charge of 2 units per item. Unit price stays 20.

Before writing code:

1. Explain the difference from the previous rule.
2. Predict totals for quantities 1, 2 and 3.
3. Identify which calculation changes and which stays the same.
4. Write the revised program for quantity 2 and add a basic assertion.
5. Rerun with the other quantities and their corresponding expected results.

One possible correction

const unitPrice = 20;
const quantity = 2;
const packingPerItem = 2;
const subtotal = unitPrice * quantity;
const packingTotal = packingPerItem * quantity;
const total = subtotal + packingTotal;
const expectedTotal = 44;
console.log("Order total:", total);
console.assert(total === expectedTotal, "Check the per-item packing rule");

The totals are 22, 44 and 66. The item subtotal calculation remains unchanged; packing now depends on quantity. Renaming the value prevents the old per-order meaning from misleading the next reader. The formerly incorrect structure could implement this new policy correctly: correctness depends on the confirmed rule.

Keep a decision journal

Write four short entries: my initial belief, the example that challenged it, my revised decision, and what remains unresolved. Include the missing validation rather than pretending the program handles every case.

Knowledge check

1. Why did quantity 1 fail to expose the original bug?
2. Why should an expected result be calculated independently?
3. What must be rechecked after a business rule changes?

Answers

1. Multiplying the packing charge by one is indistinguishable from charging it once.
2. Repeating the program's own calculation in the expectation can repeat the same mistake.
3. Check the changed behavior and behavior that should remain unchanged, using expectations derived from the revised rule.

Module review and next steps

You can now explain execution, translate a small algorithm and investigate a result. Before marking this lesson complete, demonstrate all three with your own small example and identify one unsupported input.

You have completed the first module. Continue with Variables, Data and Memory to develop these foundations. Keep your reasoning notebook: understanding, predicting and checking remain part of every exercise throughout this course.