Back to Engineering Blog
Engineering6 min read

Our Coding Challenges Had Tests That Could Not Fail

A check that searched the submission for the substring "content" passed on every HTML document ever written. Rewriting them to assert against a parsed DOM.

Glacro · Published July 28, 2026

Our developer sandbox sets front-end challenges and checks the submission. The checks were string searches against the submitted source, and most of them could not fail.

The tests that passed everything

javascript
// "Renders the content"
code.toLowerCase().includes("content")

// "Uses colour"
code.includes("rgb")

The first passes on any HTML document containing the word content — including the starter template we hand out. The second passes on any page with a single colour anywhere. A learner could submit the unmodified starter and be told all tests passed.

Asserting against a document

Checks now parse the submission with DOMParser and assert against the resulting document — is there a real button element, does the trigger carry aria-expanded, is the panel actually collapsed at rest. DOMParser builds a document without executing scripts, so running someone's submission through the checker cannot run their code in our page.

Key Takeaway
Scope matters as much as substance. A stylesheet-wide search for border-radius of at least 16px passed because of a pill-shaped button at 999px, while the card the challenge was about stayed square. Checks are now scoped to the selector under test.

Verifying the verifier

Each challenge is now checked in both directions: the starter template must score zero, and a known-good solution must score full marks. A test suite that has never been observed failing is not a test suite.

Related Articles

Product Updates

What Glacro Actually Runs, and What It Doesn't

August 26, 2026 · 6 min read
Tutorials

Deploying a Next.js 14 Static Export

August 20, 2026 · 7 min read