test: cover res.status boundaries and validation

[renanmpimentel]

The existing HTTP tests for status codes 99 and 1000 can still pass if Express's range guard is removed, because Node rejects the value later when the response ends. The tests therefore miss a regression in Express's own synchronous validation.

This test-only change:

• Checks that res.status(99) and res.status(1000) immediately raise RangeError, while preserving the existing HTTP integration checks.
• Covers the inclusive valid boundaries 100 and 999 directly, including the returned response and stored statusCode. Direct invocation avoids the special HTTP behavior of status 100.

Validation

• npm run lint: passed.
• npm run test-ci: 1,263 tests passed on Node 24.13.0/Linux.
• Isolated regression proof: disabling the range guard leaves the old HTTP assertions passing; the strengthened suite fails on exactly the two missing RangeError assertions. Restoring the guard returns all 1,263 tests to green.
• Separate inclusive-boundary regressions were detected by the new 100/999 cases and restored.
• Focused StrykerJS 10.0.0 rerun: all 17 res.status candidates classified Killed, with no timeout/runtime-error outcomes.

To reproduce the rejection proof, temporarily replace code < 100 || code > 999 with false in res.status in an isolated copy, run npm test, then restore the condition.

Audit provenance and benefit

Prepared with AI assistance using Supertest, an LLM-agnostic skill for auditing test effectiveness. The benefit was finding false confidence from downstream HTTP validation and missing inclusive-boundary cases, then proving that the corrected tests detect those specific regressions. No skill, mutation-tool dependency, or application-code change is added to Express.

Fixes #7503

[ardenash]

Please remove me from this list. I think I'm on an automatic list and would like to be removed. Thank you.

…

On Sun, Oct 4, 2026 at 5:21 PM Renan Martins Pimentel < ***@***.***> wrote: The existing HTTP tests for status codes 99 and 1000 can still pass if Express's range guard is removed, because Node rejects the value later when the response ends. The tests therefore miss a regression in Express's own synchronous validation. This test-only change: - Checks that res.status(99) and res.status(1000) immediately raise RangeError, while preserving the existing HTTP integration checks. - Covers the inclusive valid boundaries 100 and 999 directly, including the returned response and stored statusCode. Direct invocation avoids the special HTTP behavior of status 100. Validation - npm run lint: passed. - npm run test-ci: 1,263 tests passed on Node 24.13.0/Linux. - Isolated regression proof: disabling the range guard leaves the old HTTP assertions passing; the strengthened suite fails on exactly the two missing RangeError assertions. Restoring the guard returns all 1,263 tests to green. - Separate inclusive-boundary regressions were detected by the new 100/999 cases and restored. - Focused StrykerJS 10.0.0 rerun: all 17 res.status candidates classified Killed, with no timeout/runtime-error outcomes. To reproduce the rejection proof, temporarily replace code < 100 || code > 999 with false in res.status in an isolated copy, run npm test, then restore the condition. Audit provenance and benefit Prepared with AI assistance using Supertest <https://github.com/renanmpimentel/supertest>, an LLM-agnostic skill for auditing test effectiveness. The benefit was finding false confidence from downstream HTTP validation and missing inclusive-boundary cases, then proving that the corrected tests detect those specific regressions. No skill, mutation-tool dependency, or application-code change is added to Express. Fixes #7503 <#7503> ------------------------------ You can view, comment on, or merge this pull request online at: #7504 Commit Summary - c5a13bf <c5a13bf> test: cover res.status boundaries and validation File Changes (1 file <https://github.com/expressjs/express/pull/7504/files>) - *M* test/res.status.js <https://github.com/expressjs/express/pull/7504/files#diff-adb6fc008b461c5cdec8469b0d366a43b00dd70194cbb1640ee75635c1867619> (24) Patch Links: - https://github.com/expressjs/express/pull/7504.patch - https://github.com/expressjs/express/pull/7504.diff — Reply to this email directly, view it on GitHub <#7504?email_source=notifications&email_token=AAJVGTGNMRG36DB2SATSANL5SLSSBA5CNFSNUABEM5UWIORPF5TWS5BNNB2WEL2QOVWGYUTFOF2WK43UF42DOMZYG4YTENBZGCTHEZLBONXW5KTTOVRHGY3SNFRGKZFFMV3GK3TUVRTG633UMVZF6Y3MNFRWW>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAJVGTGVJFDUSQ6OYHTIE5D5SLSSBAVCNFSNUABCKJSXA33TNF2G64TZHMZDGNZRGU4TWSLTON2WKOZVG4YDINRUHA2DCOFBOYBA> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/AAJVGTB4VQFGDVUSHQ5ICPD5SLSSBA5CNFSNUABEM5UWIORPF5TWS5BNNB2WEL2QOVWGYUTFOF2WK43UF42DOMZYG4YTENBZGCTHEZLBONXW5KTTOVRHGY3SNFRGKZFFMV3GK3TUVJTG633UMVZF62LPOM> and Android <https://github.com/notifications/mobile/android/AAJVGTEJKTUJ6GR3FICS6PD5SLSSBA5CNFSNUABEM5UWIORPF5TWS5BNNB2WEL2QOVWGYUTFOF2WK43UF42DOMZYG4YTENBZGCTHEZLBONXW5KTTOVRHGY3SNFRGKZFFMV3GK3TUVZTG633UMVZF6YLOMRZG62LE>. Download it today! You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

-- *Arden Ash* www.ardenash.com c: 818.726.7950 e: ***@***.***

[ToniAdreal]

I independently verified the claims in this PR at head c5a13bf (Node 24.20.0, Linux):

• Baseline: npx mocha test/res.status.js → 18 passing (16 existing + 2 new boundary cases).
• Regression proof: I temporarily replaced the range guard in lib/response.js (if (code < 100 || code > 999) → if (false)). Exactly the two new RangeError assertions (99 and 1000, asserted directly at the status() call site) failed — all 16 other tests, including the HTTP-layer 500 assertions and the non-integer TypeError cases, stayed green.

So the new tests precisely close the discrimination gap described in the description: they pin down Express's own fail-fast range-guard contract at the call site instead of relying on Node's later rejection when the response ends. LGTM.