Skip to content

test(xmlgen): whole-document golden fixtures (3/4) - #202

Open
sthanikan2000 wants to merge 1 commit into
mainfrom
feature/xmlgen-golden
Open

sthanikan2000 wants to merge 1 commit into
mainfrom
feature/xmlgen-golden

Conversation

@sthanikan2000

@sthanikan2000 sthanikan2000 commented Sep 15, 2026

Copy link
Copy Markdown
Collaborator

Problem

The unit tests in #199 and #201 each isolate one behaviour. Nothing yet proves a realistic template end to end — that the conversions compose correctly across a whole document rather than one element at a time.

Changes

Two fixtures. Each is rendered from a data file, compared byte for byte against a golden, then unmarshalled and asserted field by field — a golden alone only tells you the output changed, the field assertions tell you whether it is still correct.

invoice exercises every conversion in one render: a reference split across four elements, two dates moved between layouts, an enum mapped to a number, a fixed-decimal amount, an empty value spelled as a <null/> marker, repeated elements filled from a table, a computed summary, a large number carrying no exponent, $. reaching the root from inside with, and text carrying an ampersand, markup, non-ASCII and embedded tabs and newlines. It is also asserted to render identically with and without WithStrictKeys — the check a template's own tests should run, since that is what turns a field renamed in a form schema from a silently blank element into a failure that names it.

envelope covers the namespaced shape: two prefixes declared at the root, the reserved xml:lang, a prefixed attribute, and a third prefix declared inside a range body so it is in scope only per iteration. It is unmarshalled by namespace URI rather than by prefix, which is what proves the declarations actually bind rather than merely appearing in the text.

TestGolden_TemplatesValidate runs Validate over every committed template, the way a registry or a CI sweep would.

Both documents are invented — shaped after the conversions a real export needs, but carrying no real registration numbers, tax identifiers, trade marks or addresses.

Testing

cd xmlgen
go test -race ./...
go test ./... -update   # regenerate the goldens after an intended change

155 subtests cumulative (17 added), race-clean, 0 lint issues. A tampered golden fails the suite, so the fixtures are load-bearing rather than decorative.

Separately, and not committed because it carries live business data, I rendered a template against a real SLTB blend sheet and its form JSON: 17 of 20 fields identical, all 25 repeated rows, all 7 empty-value markers, and a multi-line warehouse address round-tripping exactly. The three differences are legacy Java number formatting we chose not to reproduce — 8522 vs 8522.0, 162 vs 162.0, 16336200 vs 1.63362E7. Worth revisiting before the first live submission if the consuming system turns out to be a legacy reader rather than a real parser.

Related

Implements #189. Stacked chain — 3 of 4:

#199 engine → #201 helpers and resolvers → #202 (this)#200 failure paths

Summary by CodeRabbit

  • Documentation

    • Documented the command for updating golden test files after intentional output changes.
  • Tests

    • Added golden tests for invoice and SOAP envelope XML rendering.
    • Added validation coverage for committed templates, including formatting, escaping, namespaces, repeated elements, empty values, and numeric/date conversions.
    • Added representative invoice and envelope templates, input data, and expected XML fixtures.

@coderabbitai

coderabbitai Bot commented Sep 15, 2026

Copy link
Copy Markdown

Review Change StackReview Change Stack

Important

  • 🔍 Trigger review

This repository does not receive automatic reviews because it has fewer than 10 stars.

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Advanced

Run ID: 246cf89c-f99d-4398-bcf3-04cee36497ed

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info
⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Advanced

Run ID: 1410345d-2b46-4fc5-b722-79432c476450

📥 Commits

Reviewing files that changed from the base of the PR and between d3606ff and 706548c.

📒 Files selected for processing (8)
  • xmlgen/README.md
  • xmlgen/golden_test.go
  • xmlgen/testdata/envelope.golden.xml
  • xmlgen/testdata/envelope.json
  • xmlgen/testdata/envelope.tmpl
  • xmlgen/testdata/invoice.golden.xml
  • xmlgen/testdata/invoice.json
  • xmlgen/testdata/invoice.tmpl

Included review availability: Your plan provides up to 1 included review per hour; 0 remain after this review.


📝 Walkthrough

Walkthrough

Changes

The PR adds golden tests for invoice and SOAP envelope XML rendering. It adds JSON inputs, templates, expected XML outputs, template validation, and a README command for updating golden files.

XML golden rendering coverage

Layer / File(s) Summary
Golden-test harness
xmlgen/golden_test.go, xmlgen/README.md
The test suite renders fixtures, checks markers, supports golden-file updates, and validates all committed templates. The README documents go test ./... -update.
Invoice rendering fixtures
xmlgen/testdata/invoice.*
Invoice fixtures cover field conversion, formatting, interpolation, repeated lines, escaping, derived totals, and null values.
Envelope rendering fixtures
xmlgen/testdata/envelope.*
Envelope fixtures cover namespaces, attributes, date and reference conversion, repeated documents, escaped text, and Unicode characters.

Priority: ⬇️ Low

Estimated code review effort: 3 (Moderate) | ~20 minutes

Change: Other

Merge Risk: 🔵 Low · up to 70654

A future rendering regression that removes invoice lines would produce a panic instead of the intended cardinality failure. Add the guard before merging for reliable test diagnostics.

🚥 Pre-merge checks | ✅ 5
✅ Passed checks (5 passed)
Check name Status Explanation
Title check ✅ Passed The title clearly identifies the xmlgen whole-document golden fixture tests and matches the main changes.
Description check ✅ Passed The description clearly explains the problem, fixtures, covered behaviors, validation, testing results, related issue, and stacked PR context. It does not use every template heading, but it contains t…
Docstring Coverage ✅ Passed Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 4 functions across 1 files. (7 skipped: 7 …
Linked Issues check ✅ Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check ✅ Passed Check skipped because no linked issues were found for this pull request.
✨ Finishing Touches
📝 Generate docstrings
  • Commit to this branch
  • Create a new PR
🧪 Generate unit tests (beta)
  • Commit to this branch
  • Create a new PR

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

@sthanikan2000
sthanikan2000 added this pull request to stack #204 September 16, 2026 04:55
@sthanikan2000 sthanikan2000 self-assigned this Sep 16, 2026
@sthanikan2000 sthanikan2000 reopened this Sep 17, 2026
Base automatically changed from feature/xmlgen-helpers to main September 17, 2026 16:08
The unit tests each isolate one behaviour. These prove a realistic template
end to end: rendered from a data file, compared byte for byte against a
golden, then unmarshalled and asserted field by field, so both the exact
bytes and the semantic content are pinned.

invoice exercises every conversion in one render -- a reference split across
four elements, two dates moved between layouts, an enum mapped to a number,
a fixed-decimal amount, an empty value spelled as a marker element, repeated
elements filled from a table, a computed summary, and text carrying an
ampersand, markup, non-ASCII and embedded tabs and newlines. It is also
asserted to render identically with and without strict keys, which is the
check a template's own tests should run: it is what turns a field renamed in
a form schema from a silently blank element into a failure that names it.

envelope covers the namespaced shape: two prefixes declared at the root, the
reserved xml: prefix, a prefixed attribute, and a third prefix declared
inside a range body so it is in scope only per iteration. It is unmarshalled
by namespace URI rather than by prefix, which is what proves the
declarations actually bind rather than merely appearing in the text.

Both documents are invented. They are shaped after the conversions a real
export needs, but carry no real registration numbers, tax identifiers or
trade marks.

Refs #189

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant