While solving this exercise I wrote two different fail_safe implementations with logic bugs in the NORMAL-range boundary calculation, and both passed the full test suite:
elif indicator>=threshold*-0.1 or indicator<=threshold*0.1 — using or instead of and for a range check, so the condition is true almost regardless of indicator.if indicator<=threshold+variation>=indicator — a chained comparison that reduces to a single repeated condition, silently dropping the lower bound.
I know a finite test suite can't cover every case, and I saw #2775 raised something similar and was closed for that reason. But I think this specific failure mode deserves a second look, because of which case slips through: this exercise is precisely where learners practice range logic (and vs or, chained comparisons). A learner who gets or vs and backwards, or who accidentally collapses a chained comparison into a repeated single condition, is exactly the person this exercise is meant to catch — and the current suite doesn't.
A test failing is a teaching moment. A test silently passing on broken range logic teaches the learner the wrong thing is correct, and that misunderstanding travels forward into every future exercise involving ranges.
One added case (e.g. indicator far below threshold, values chosen so a broken lower-bound formula misclassifies it as NORMAL) would close this without needing broad coverage — it just needs to specifically target the and/or boundary mistake.
(Related: #2775 raised a similar concern and was closed — flagging in case this framing is more actionable.)
While solving this exercise I wrote two different
fail_safeimplementations with logic bugs in the NORMAL-range boundary calculation, and both passed the full test suite:elif indicator>=threshold*-0.1 or indicator<=threshold*0.1— usingorinstead ofandfor a range check, so the condition is true almost regardless ofindicator.if indicator<=threshold+variation>=indicator— a chained comparison that reduces to a single repeated condition, silently dropping the lower bound.I know a finite test suite can't cover every case, and I saw #2775 raised something similar and was closed for that reason. But I think this specific failure mode deserves a second look, because of which case slips through: this exercise is precisely where learners practice range logic (and vs or, chained comparisons). A learner who gets or vs and backwards, or who accidentally collapses a chained comparison into a repeated single condition, is exactly the person this exercise is meant to catch — and the current suite doesn't.
A test failing is a teaching moment. A test silently passing on broken range logic teaches the learner the wrong thing is correct, and that misunderstanding travels forward into every future exercise involving ranges.
One added case (e.g. indicator far below threshold, values chosen so a broken lower-bound formula misclassifies it as NORMAL) would close this without needing broad coverage — it just needs to specifically target the and/or boundary mistake.
(Related: #2775 raised a similar concern and was closed — flagging in case this framing is more actionable.)