Tool Testing Methodology — Dev Utilities

Why this page exists

90+ tools on this site produce output that people copy directly into real code, configs, and production systems — a formatter that mangles a value, or a hash generator that computes the wrong output, causes real harm downstream. This page explains what actually verifies correctness before a tool ships and stays correct after it ships, not just what we intend to do.

Automated test suite

Every tool's core logic — parsing, formatting, encoding, hashing, validation — is covered by unit tests (Vitest) that check known inputs against known-correct outputs, including edge cases (empty input, malformed input, boundary values). Component tests verify that the UI actually calls that logic correctly and displays the result. The full suite runs before any change is considered complete; a failing test blocks the release rather than being noted and shipped anyway.

Build-output verification, not just source review

This site is a fully static export — what matters is what actually ends up in the generated HTML, not what the source code appears to do. Changes are verified by running a real production build and inspecting the generated output directly: checking that a tool page actually renders its content, that metadata and canonical tags resolve correctly, and that interactive elements aren't silently empty in the static HTML a search engine or a first-time visitor actually receives. Reading source code alone has, more than once, missed a real rendering bug that only showed up in the built output — so build verification is a required step, not an optional one.

Automated quality scoring

Every page — tool pages, guides, reference pages, blog posts — is scored automatically after each build against word count, heading structure, internal links, FAQ presence, and structured data. Pages that fall below a minimum quality threshold are automatically marked non-indexable rather than left to accumulate as thin content; pages far below that threshold fail the build outright. This runs on every single build, not as an occasional manual audit.

Manually verified examples

Worked examples shown on tool pages (sample inputs and their expected outputs) are computed independently — for example, a Base64 or SHA-256 example is checked against a real, independent computation of the same value — rather than typed from memory. A wrong example on a page whose whole purpose is trustworthy output is a correctness bug, not a cosmetic one, so examples are treated with the same scrutiny as the tool's underlying logic.

Privacy and security checks

For every tool, we verify what actually leaves the browser: purely client-side tools (formatters, encoders, hash and password tools) are checked to confirm no network request fires when they run. Tools that inherently require a server call — DNS lookups, SSL/WHOIS checks, ping — are checked to confirm they send only the input needed for that specific lookup and nothing else. This distinction is documented per tool in each tool page's trust card, not just asserted in the abstract.

Browser compatibility

Tools are built on standard, widely-supported browser APIs and tested across current versions of Chrome, Firefox, and Safari, in both light and dark mode. When a tool depends on a newer browser API, that dependency is called out rather than left to fail silently for an unsupported browser.

What this doesn't cover

Testing reduces the rate of errors — it doesn't eliminate it. As stated in our Terms of Service, always independently verify critical tool output before relying on it in production, security, or legal/financial contexts. If you find a case where a tool's output is wrong, that's exactly the kind of report that improves this process — tell us the tool, your input, and what you expected.

Ecosystem-wide policies

This page covers testing specific to Dev Utilities. For how AI is used, how data is handled, and a public record of changes across all Sedulous Web products, see the Sedulous Web Trust Center and public changelog.