Checklist
Give omitted, null and blank different test cases
An empty-looking cell can carry a very active instruction.
When it fits
- A mass update may clear existing values when the intended action was to leave them alone.
When to avoid it
- Do not standardize all missing representations into one value before checking their semantics. Different fields in the same interface can behave differently.
Checklist
- Read the field-level update contract, including flags and defaults.
- Test omitted, null, empty-string and explicit-value inputs against an existing nonempty value.
- Inspect the stored result and any downstream message before approving a bulk run.
Why it matters
Write down how this exact interface represents no change, clear the value and set an empty string. Do not infer those meanings from appearance. JSON Merge Patch, for example, gives null a removal meaning; another interface may use an update flag or a different convention.
An example
A file omits an email column in one test and includes it empty in another. Only the documented behavior determines whether either clears the address.
Check your result
Each input state has an observed, documented target effect.
Keep this limit in mind
- Do not standardize all missing representations into one value before checking their semantics. Different fields in the same interface can behave differently.
Connected ideas
Useful withFind the first boundary where the record becomes wrong
Evidence and sources
Supports
JSON Merge Patch distinguishes an omitted member from a member set to null: null requests removal of that member.
This is one interface contract, not a universal interpretation of empty spreadsheet cells or null values.
RFC 7396: JSON Merge Patch · Sections 1 and 2