What is wrong
__tests__/update-contents.test.ts checks anchors by asserting the output of headerToAnchor against values derived from the same algorithm:
expect(result[sectionToken]).toContain('- [Introduction](#introduction)');
expect(result[sectionToken]).toContain('- [Hello, World!](#hello-world)');
These pass whenever the implementation is self-consistent. They do not compare the generated anchor with the anchor the rendering target actually produces.
Why this matters for validating work in this repository
#651 records that the algorithm diverges from GitHub's for two reachable classes of heading — non-ASCII letters and punctuation producing repeated separators:
| heading |
tool emits |
GitHub's anchor |
Ünïcödé Héading |
#ncd-hading |
#ünïcödé-héading |
Setup & Config! |
#setup-config |
#setup--config |
The existing tests cannot detect either, because they encode the same assumption the implementation makes. A test that pins behaviour to the implementation confirms the code does what it does; it says nothing about whether the produced links resolve.
The generated table of contents exists to produce working links on GitHub, so conformance to GitHub's slug algorithm is the property worth asserting.
Impact
This is a general shape of test worth checking for elsewhere in the suite: assertions written from the implementation rather than from the contract pass by construction. Here it left a class of broken output undetected.
What is wrong
__tests__/update-contents.test.tschecks anchors by asserting the output ofheaderToAnchoragainst values derived from the same algorithm:These pass whenever the implementation is self-consistent. They do not compare the generated anchor with the anchor the rendering target actually produces.
Why this matters for validating work in this repository
#651 records that the algorithm diverges from GitHub's for two reachable classes of heading — non-ASCII letters and punctuation producing repeated separators:
Ünïcödé Héading#ncd-hading#ünïcödé-héadingSetup & Config!#setup-config#setup--configThe existing tests cannot detect either, because they encode the same assumption the implementation makes. A test that pins behaviour to the implementation confirms the code does what it does; it says nothing about whether the produced links resolve.
The generated table of contents exists to produce working links on GitHub, so conformance to GitHub's slug algorithm is the property worth asserting.
Impact
This is a general shape of test worth checking for elsewhere in the suite: assertions written from the implementation rather than from the contract pass by construction. Here it left a class of broken output undetected.