iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
The most useful tests for a registry-driven website check the promises that content makes, not the code that renders it. TypeScript can confirm that a provider ID belongs to a union type. It cannot confirm that every registry contains that provider, that a page promised by a registry exists on disk, that a derived price matches the catalogue, or that a rendered title stays within a length rule. Daniel Pertu’s DEV Community essay makes this case using CogniPrep, a content-heavy Next.js application whose registries feed practice tests, provider hubs, guides, blog posts, employer pages and format pages. Pertu’s project figures and examples are his own account and have not been independently verified. This article sets out the kinds of assertions his argument points toward, why each one matters, and how to write them.
What a type check cannot see
A type system reasons about values in memory at compile time. A content registry is a set of plain data objects, and the promises attached to them point outward: to a sitemap, to a URL, to a file on disk, to a price tier, to a sentence a reader will see. Pertu’s phrase for the gap is blunt: “The compiler has no opinion about facts.”
Three failure modes follow directly from that gap:
- Missing structure. A registry lacks an entry that other parts of the site expect, or an entry exists but its generated output is incomplete.
- Dangling promises. A registry feeds a sitemap, the sitemap lists a URL, and the page behind that URL was never built. The URL then returns a 404 while every type check passes.
- Silent falsehoods. A value is well formed but wrong: a derived number is stale, a product name is attached to the wrong company, or a figure that has not been published gets filled in with a plausible guess.
Tests written for these cases are not checking the programming language. They check the claims the site makes to its readers and to search engines.
Assert that promised files exist
When a registry entry implies a page, the test should confirm that the page exists. Pertu’s example is a route promise: a registry feeds a sitemap, so every URL in that sitemap is a promise that a route exists. The typechecker does not establish that filesystem fact, so a test has to.
In Pertu’s project the registration tests check for files with existsSync. He reports one registration test per provider, 40 such tests in total, carrying 193 existsSync assertions between them. Across the suite he reports 304 files and 6,563 tests, with a Vitest run of about 16 seconds. These are his figures for his project on his machine. They describe the scale of one setup, not a benchmark anyone should expect to reproduce.
A practical pattern for a registry of this kind:
- For each entry, list every URL or page the entry is expected to produce: the hub, the guide, the blog post, the employer page, the format page.
- Map each URL to the file path that should back it, following your framework’s routing conventions.
- Assert that each path exists, and fail with a message that names the registry entry, so the regression is traceable.
- Keep the sitemap generator in the same test run, so that an entry added to the registry without a page fails before deployment.
Check boundaries between files
Some of the most useful checks are cheap source-level reads that cross a file boundary. Pertu’s example reads two component files and checks that every icon name used for a provider’s games appears in both icon maps. Nothing in the type system ties those two maps together, so a new game added to one map but not the other will fail a single assertion rather than surface as a blank icon in production.
Pertu acknowledges that this kind of check is crude. It reads source text, it is not elegant, and it can break on harmless refactoring. He argues that it is still worth writing because it is quick, narrow and loud when it fails. The same reasoning applies to any integration seam where two files must agree and nothing enforces it.
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Fix the driver behind crashes, sound loss and screen glitches3Repair Windows errors before they cause bigger problemsDerive expected values instead of hard-coding them
A price test is a useful illustration. A hard-coded expectation, such as “this provider costs a given amount,” tells you only that the number has not changed. It says nothing about whether the number is right for the catalogue behind it.
Pertu’s alternative is to derive the expected tier from the size of the playable catalogue and compare that tier with the provider’s listed price. When the catalogue grows, the test exposes a price that no longer matches its tier, rather than passing because someone updated a constant. The assertion encodes the business rule, and the rule is what should be protected.
Guard against false associations
Factual tests also work as negative guards. Pertu notes that Criterion is a Clevry product, and that Criteria is an unrelated assessment company. Because the two names are close, it is easy for a description written for one to drift into the other. A test that rejects the Criterion name inside the Criteria description prevents the site from publishing a false association, and its only purpose is that prevention.
Negative guards are most valuable where a near-match is plausible. Write them for the confusions your own content is actually exposed to, not for every conceivable error.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Keep unknown values unknown
A missing fact should stay missing. Pertu’s test expects the field publishedAverageSeconds to be null where an expert average has not been published. The point is that a plausible-looking number, filled in because a page would look better with one, is a claim the site cannot support.
This is easy to get wrong in a content pipeline, where defaults and fallbacks are convenient. A test that asserts null for unpublished data turns an accidental fill-in into a visible failure, and forces a decision about whether the data should be sourced or the page should omit the figure.
Rank #4
Test the rendered output, not only the source
The most important shift in Pertu’s argument is from the value in the registry to the value the reader gets. A title stored as a string is not the title a visitor sees, because the layout adds text around it.
Pertu’s example is a title-length rule. The layout template appends | CogniPrep, which is exactly 12 characters. A rule that titles must be under 60 characters therefore means a 48-character title renders at 60, which breaks the rule. A test that checks only the registry string passes; the rendered page fails. Pertu’s project changed the assertion to require less than 48 characters, equivalently 47 or fewer, and also audits the prerendered HTML after a build, so the check runs against the output a crawler receives.
Windows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallCrashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteThe table below lists the rendered title and description lengths Pertu reports for example pages on his site. He presents them as examples from his app, not as general limits.
Best Value
| Page (as reported by Pertu) | Rendered title length (characters) | Rendered description length (characters) |
|---|---|---|
| Clevry hub | 57 | 154 |
| Clevry guide | 58 | 146 |
| Clevry blog | 55 | 157 |
| TestGorilla hub | 55 | 153 |
| Royal Mail employer page | 42 | 150 |
The lesson is the measurement point. Measure the characters the reader receives, after the template has added whatever it adds.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.A checklist drawn from the author’s questions
Pertu frames the audit around three questions. They work as a review checklist for any registry-driven site:
- What does a missing registry entry do? Identify every consumer of the registry, including sitemaps, navigation, search and price tiers, and decide whether a gap should fail the build or fail a test.
- Which promises does an entry make about files that exist? List the routes, pages and assets each entry implies, and assert that each exists on disk.
- What must never be said? Write down the false associations, guessed figures and out-of-date claims the site must not publish, and write a test for each.
Judging test quality
Pertu cautions against reading the suite’s size as its value. A test count or a runtime says little about whether the tests protect anything. In his framing the useful property is precision: an assertion tied to a specific promise and to observable output. His own words put it this way: “The number you assert on is not the number you care about.” A test that asserts a convenient internal number can pass while the reader still receives the wrong title, the wrong price or a broken link.
When you review a suite, ask what observable thing each test would catch if it failed. If the answer is “a constant changed,” the test may be protecting nothing a reader sees.
What the evidence supports
The argument, the examples and the figures come from one article by one author describing one project. The counts, runtime, character lengths and company descriptions are the author’s account and have not been checked against an independent source. The general approach, asserting factual and structural promises against files and rendered output, does not depend on those numbers and can be applied to any registry-driven site. Readers adopting it should verify the specifics of their own framework and test runner rather than assume the figures transfer.
The original essay is on DEV Community: Our most valuable tests do not test code, they assert that our content is true, by Daniel Pertu, posted 1 October.
Quick Recap
“
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
Recommended Free Tools
