Tests and Code Reviews
Check the pass rule before trusting the report
A report says a student with mark 25 failed even though the school passes marks of 25 or more. One successful test at mark 40 would not catch this boundary mistake.
A test compares actual behavior with an expected result. A code review examines whether a change meets its requirements and remains understandable. Tests and reviews complement each other; neither proves every possible behavior.
Select useful cases
Cover ordinary, boundary and invalid values.
Run assertions
Use checks that fail when a result is wrong.
Review the change
Explain requirements, missing cases and readable implementation.
Turn the stated school rule into observable checks
Requirement
Agree on the threshold and accepted inputs.
Pass at 25 or aboveCases
Choose below, exactly at and above the boundary.
24, 25, 40Comparison
Compare actual outputs with expected outputs.
false, true, true
Expected behavior comes from the requirement, not the code
If tests copy the same mistaken > comparison as the implementation, both can agree while violating the school’s >= rule. Write expected results from the requirement first.
A regression test records a case that previously failed, helping detect its return after later changes. A unit test checks a focused operation; broader integration checks verify cooperating parts such as saving and loading a report.
Before starting, review inclusive and exclusive comparisons. These examples use JavaScript; other languages can use different syntax and rules.
Check the pass boundary and its neighbors
Each log compares the returned boolean with the expected boolean. All three true outputs mean those comparisons matched; they do not mean every student passed.
The boundary case at 25 distinguishes >= from >. Testing only mark 40 would miss that specific error.
JavaScript · local teaching example
function hasPassed(mark) {
return mark >= 25;
}
console.log(hasPassed(24) === false);
console.log(hasPassed(25) === true);
console.log(hasPassed(40) === true);Expected output
true
true
trueRun assertions that fail the check automatically
JavaScript for Node.js · Save this as pass-test.cjs and run node pass-test.cjs. assert.equal throws if an actual result differs from its expected value. When all assertions pass, the final message displays Pass checks succeeded.
Changing >= to > makes the assertion for mark 25 fail before that final message. This is a real executable check, not a testing-framework simulation.
const assert = require("node:assert/strict");
function hasPassed(mark) { return mark >= 25; }
assert.equal(hasPassed(24), false);
assert.equal(hasPassed(25), true);
assert.equal(hasPassed(40), true);
console.log("Pass checks succeeded");Apply the rule to a small change
Validate that marks are finite numbers from 0 to 50, then test a valid boundary, a negative mark and a numeric-looking string.
Worked answer
A valid numeric mark 25 passes. Negative -1 is rejected by the range check; string "35" is rejected by Number.isFinite rather than being silently converted. Each comparison below prints true when that expected behavior is observed.
JavaScript · local teaching example
function hasPassed(mark) {
if (!Number.isFinite(mark) || mark < 0 || mark > 50) {
throw new Error("Invalid mark");
}
return mark >= 25;
}
console.log(hasPassed(25) === true);
for (const invalid of [-1, "35"]) {
try {
hasPassed(invalid);
console.log(false);
} catch (error) {
console.log(error.message === "Invalid mark");
}
}Expected output
true
true
trueReview the requirement and the change together
A reviewer should ask whether the threshold is inclusive, whether invalid inputs are rejected at the agreed boundary and whether callers know how failure is reported. Check names and responsibilities as well as arithmetic.
Compare the change with its requirement and inspect useful tests. Ask for a missing boundary or failure case rather than merely requesting more tests. Reviewers can catch assumptions that a chosen test set does not exercise.
Keep a review focused on the change and explain the consequence of a finding. For example: “Using > rejects mark 25, but the school rule includes 25; use >= and keep this boundary check.”
Recognize mistakes and limits
Passing tests provide evidence for the chosen cases, not a guarantee for all inputs or environments. Real file operations, UI behavior and asynchronous failures may need separate checks.
Avoid tests that only repeat an implementation detail. Test the promised result and important failures so a clearer internal implementation can still satisfy the same behavior.
Do not hide failures by catching every error and declaring success. Assertions and failures should be visible, and a failed test needs investigation before a change is accepted.
For the language or tool rules used here, see Node.js assertion behavior.
Check the core idea
Apply the idea to a new situation
JavaScript · code for this question
function hasPassed(mark) {
return mark >= 25;
}
console.log(hasPassed(24) === false);
console.log(hasPassed(25) === true);
console.log(hasPassed(40) === true);Use requirements, focused checks and reasoned review together
Choose tests from expected behavior, include boundaries and failures, and use assertions that make mismatches visible. Review assumptions and clarity alongside the checked results.
Connect this idea with investigating a failed check and recording a verified change.
Reaching the recap and completing the quizzes are separate milestones.