A text-to-image page can look like a single form, but the user is relying on several contracts at once: the text must survive input, options must persist, generation must be distinguishable from preview, and the downloaded file must match what was reviewed. Retro styling adds another contract because the visual treatment can change whether a digit or pixel gap remains readable.
This is a black-box test plan based only on the public surface. It does not assume a framework, an API, a model, or private implementation details.
Define the observable surface
The public Fontify workflow provides a useful boundary for test design: enter wording, choose visual settings, generate a preview, and save an image. The exact DOM selectors should be discovered in the current editor before automation. The test plan can still be written first.
| Surface | Contract to observe | Failure worth recording |
| --- | --- | --- |
| Route | The requested page loads the intended style | A link opens a different template |
| Input | Text remains visible after editing options | Characters disappear or normalize silently |
| Options | Color, background, and ratio stay selected | A setting resets during generation |
| Generation | Busy, success, and error states are distinguishable | Double-click creates ambiguous results |
| Preview | The result can be inspected before saving | The edge of a title is clipped |
| Download | The saved asset matches the preview | Format, ratio, or background changes |
These are external contracts, not claims about how the product is built.
Keep number tests different from pixel tests
The Retro Number Font Generator deserves cases that expose numeric ambiguity. Use a short time, a long score, repeated digits, and values with similar silhouettes. A compact matrix might include 08:08, 2400, 1996, 5.06, and a price-like string. Verify that the input, preview, and saved file preserve every character; do not treat a successful request as proof of legibility.
Pixel lettering needs a second matrix. The Retro Pixel Font Generator presents modular, block-built lettering with sharp corners and separated characters, plus controls for font color, background, and an output setting such as 2K · 16:9 · PNG. Test a one-word title, a long title, repeated letters, punctuation, and a mixed-case phrase. At the intended display size, inspect narrow gaps, stepped corners, and the baseline rhythm.
type TypographyCase = {
route: 'number' | 'pixel';
text: string;
viewport: 'mobile' | 'desktop';
expected: 'preview-review' | 'download-review';
};
This is a proposal for discussing test data, not a type copied from the site.
Model the flow as states
A reliable bug report names the transition where the contract broke. A minimal, observable model is:
idle -> edited -> generating -> previewReady -> downloaded
| |
+-> error <------+
For each transition, record the exact text, viewport, selected ratio, color/background choices, and whether the issue appears in preview or only in the file. Keep previewReady and downloaded separate: a preview can look correct while an exported asset uses a different canvas or background.
Add responsive and content-boundary cases
Retro display text is often used in places with hard edges: scoreboards, tickets, game headers, labels, and social cards. A desktop pass alone is insufficient. Re-run the same cases on a narrow viewport and at the smallest plausible thumbnail.
Boundary inputs should include:
an empty or whitespace-only value, if the editor allows submission;
the shortest valid value and a deliberately long title;
repeated characters such as 1111, MMMM, or 0000;
punctuation and separators used in times, scores, and prices;
characters outside the demonstrated alphabet, with the resulting guidance captured;
a background image or transparent-looking setting, if exposed by the current UI.
Do not assume that “free to use” on a public page answers commercial licensing for every project. Make license review a release checklist item, not an automated pass.
Separate functional QA from visual QA
Functional checks can confirm routing, input retention, button states, and the existence of a download. Visual QA must answer different questions: are similar digits distinguishable, do pixel gaps survive reduction, is contrast adequate, and does the composition leave room for supporting copy?
When automation is added, use only accessibility names and selectors verified against the live page. A guessed selector is not a test; it is an unexecuted example. Keep screenshots or downloaded fixtures attached to the test run when policy permits, because a later reviewer needs to see whether a failure is functional, visual, or simply a content choice.
A small release checklist
Before handing a generated asset to a designer or engineer, confirm:
The route title and style match the intended number or pixel task.
Text and options survive generation without silent resets.
The preview is reviewed at final size and on a narrow viewport.
The downloaded format and canvas match the selected settings.
Similar digits, repeated letters, and punctuation remain readable.
Commercial use and output-format requirements are checked separately.
The practical lesson is broader than retro typography: treat the preview and the saved artifact as separate contracts. Once those boundaries are explicit, a small generator becomes much easier to test without pretending to know anything about its private internals.
Top comments (0)