sass-testlisted

# Write a sass-true test ## Where a hand-written spec fits The suite tests every member at four depths. Know which one you are adding to: | Level | Proves | Coverage | |---|---|---| | smoke (`test/smoke.scss`) | the mixin evaluates | 53/53 mixins | | snapshot (`meta/` examples) | its output cannot change unnoticed | 76/76 members | | rejection (`meta/` rejects) | bad input is refused, with the library's own message | 47/76 | | **sass-true spec** | **the CSS is correct** | **12/76** | The first three come free from a `meta/` entry. A sass-true spec is the only one that says the output was right in the first place — a snapshot of a wrong value records it as correct. So it is worth writing when the mixin **computes** something: arithmetic, a percentage, a polygon, a shorthand order, gradient positions. It is usually not worth it for a mixin that emits a few fixed declarations, where the snapshot already covers everything and the assertion would just be maintenance. Existing examples to copy from: `triangle`, `scissors`, `columnizer`, `position`, `background-dots`, `ratio-box`, `responsive-video`, `remove`. ## Derive the expectation, do not paste it Write what the CSS *should* be from the technique, then run it. Pasting the compiled output turns the spec into a second snapshot and it can only ever agree with the code. This is not theoretical: deriving `columnizer`'s widths independently is what revealed it interpolates its `calc()` instead of evaluating it, so `calc(100%