Build a JSON Round-Trip Test Before Migrating Data
Test missing values, large identifiers, and nested structures before trusting a parse-and-stringify migration.
A JSON migration can preserve valid syntax and still change the meaning of a record. A useful check compares the source, parsed value, and serialized result with deliberately chosen fixtures. This walkthrough uses synthetic records rather than production data and separates a formatting check from a data-preservation check. The sample cases are designed to expose questions your migration needs to answer.
Define what must survive
List the fields whose exact representation matters: identifiers, optional properties, arrays, and date strings. An identifier can be text even when it contains only digits. If leading zeros matter, the source schema should use a string. A formatter cannot recover zeros already removed by another system.
For each field, decide whether you are checking exact text, value equality, or a business rule. Pretty printing changes whitespace outside strings, so a raw text comparison will flag harmless changes as well as meaningful ones.
Create fixtures for absent and explicit values
Use separate records for an absent property, a property containing null, an empty string, zero, and false. These are different states. A cleanup step that removes every falsy value can erase legitimate answers. Write the expected result for each case before running the migration.
Also include an empty array and an array with one element. A downstream consumer may distinguish “no items” from “field not supplied.” Your test should preserve that distinction or document a deliberate conversion instead of letting it happen accidentally.
Keep large identifiers out of number arithmetic
JavaScript Number cannot exactly represent every integer beyond its safe-integer range. If a JSON record contains a very large numeric identifier, parsing can lose precision before you stringify it again. Visually inspecting a formatted output is a weak way to detect that loss.
Use a synthetic identifier such as "9007199254740993" as a string and assert it stays identical. If an external schema requires a numeric token, select a parser and storage strategy that preserve it. Changing the type unilaterally may break a consumer, so make the contract explicit.
Compare structured results and intentional exceptions
Parse a fixture, serialize it, parse the result, and compare the structures. Then compare exact strings for fields that require textual identity. Remember that undefined values introduced in JavaScript do not behave like null during serialization: object properties can disappear.
Keep a small table of permitted transformations, such as sorting a known tag array or adding a schema version. Everything outside that table should remain stable. Do not use a broad text replacement to normalize data whose structure you can inspect directly.
Promote the check into the release process
Run the fixtures against the same migration code you will deploy. Save expected outputs and a short explanation for each edge case. When one fails, inspect the earliest stage where the value changes instead of adjusting the final comparison to accept the damage.
Use the JSON formatter for inspection and the text diff tool for readable output comparisons. Neither establishes your business contract automatically. A passing round-trip suite means your selected cases survived; expand it when you discover another shape in real data, using an anonymized synthetic equivalent.
| Case or stage | Detail | What to notice |
|---|---|---|
| Missing key | {} | Different from null |
| Text identifier | "00127" | Keep leading zeros |
| Large identifier | "9007199254740993" | Preserve as agreed text |