Render tests assert only that a file was written, so an empty chart passes

[davidnmbond]

Summary

FormatTests and SvgTests assert only that a file was produced. They pass whether or not the chart contains anything, which is why #27 — raster output containing no chart content at all — is invisible to CI.

Detail

The existing shape is roughly:

SaveFile(BasicChartSpecification, fileInfo);
// assert the file exists / has non-zero length

A renderer that emits a valid, well-formed, entirely empty image satisfies that. Confirmed: with #27 present, all five tests pass while the PNG is a solid purple rectangle.

Byte count alone is not enough either. The blank PNG in #27 is 5,323 bytes, because a large single-colour fill still compresses to something non-trivial.

Suggested assertions

Cheap and high-value, roughly in order:

1. SVG element census. SVG is text, so this is the easiest real assertion available: parse the output and require at least one path (or polyline), and a text count matching the expected labels. For BasicChartSpecification today that is 7 path, 7 text, 80 use, 4 circle. Asserting "at least one path per series" would have caught Raster (PNG/JPEG) output contains no chart content, while SVG of the same chart is complete #27 immediately for the raster case if applied there too.
2. Raster distinct-colour count. Decode the PNG and require more than a small number of distinct pixel colours. A chart with four series, axes and a legend cannot legitimately be one or two colours. This is the assertion that directly catches Raster (PNG/JPEG) output contains no chart content, while SVG of the same chart is complete #27.
3. Cross-format consistency. Render the same chart to SVG and PNG and assert both are non-trivial. The current bug is precisely a divergence between the two renderers, and no test compares them.
4. Golden-image comparison, if you want tighter cover: store a reference PNG and compare with a tolerance. More maintenance, but it catches subtle regressions that a census will not.

Options 1 and 2 together are probably the best value: they are deterministic, need no reference files, and would have failed loudly on #27.

Why it matters beyond this bug

ChartMagic is the intended replacement for a Windows-only chart renderer in Magic Suite, and the acceptance criteria there are pixel-comparison based. A library whose own tests cannot tell a working renderer from an empty one makes that migration hard to trust, independently of whether #27 is fixed.

Environment

PanoramicData.ChartMagic at 368b81b (main), .NET 10.