Generate
Your application writes actual.xlsx.
Excel regression testing
Run the same workbook comparison after an export job, application release, or data-pipeline change. WorkbookLens CLI returns an actionable exit code and saves evidence for the person who investigates.
A durable test pattern
Your application writes actual.xlsx.
WorkbookLens checks it against approved.xlsx.
The job reads the exit code and retains the reports.
.workbooklens.exe ".aselinesapproved.xlsx" ".outputactual.xlsx" --keyed "Orders:A" --html ".artifactsworkbook-diff.html" --json ".artifactsworkbook-diff.json"
if ($LASTEXITCODE -eq 1) { throw "Excel report changed; review workbook-diff.html" }
if ($LASTEXITCODE -eq 2) { throw "Workbook comparison could not run" }Reduce false alarms
Generated reports often sort differently after a database query, dependency update, or harmless implementation change. If a worksheet represents records, use a stable key such as Orders:A so the test follows each order ID.
This turns a noisy row-by-row mismatch into a focused result: records added, records removed, and fields changed within records that still exist.
Good regression controls
Store a known-good workbook produced from controlled input. Replace it only after a reviewer accepts the intended change.
HTML supports review; JSON supports dashboards, notifications, and downstream analysis.
Treat exit code 1 as a comparison finding and exit code 2 as an execution problem. They require different investigations.
Implementation questions
No. WorkbookLens is self-contained and reads the workbook directly.
Yes. The HTML report is self-contained and can be archived as an ordinary build artifact.
That depends on your release control. A common pattern is to fail or flag the job, attach the HTML report, and require a reviewer to approve a new baseline when the change is intentional.