While working on the Intranet Suite Stats Counter Web Part in August, I provisioned the Stats Counter starter list using our built-in “stats counter list starter template”, and three cards showed a dash. Another showed “10 days” where it should have shown “75%.”
This was our own sample data. I expected it to provision the list, add the web part, and the examples should work without anyone having to repair any item – less friction for end-user.
There were already twelve test assertions for the starter rows that were passing. But the tests supplied handwritten calculation rules. The actual seed-row type was missing Rule property values, and the provisioning code forgot to write it to the SharePoint list.
So the test rows had information the real rows didn’t.
With the Rule cells empty, the model fell back to counting days. Three rows had no date to count from, so they displayed dashes. The percentage example went through the day-count calculation too. That accounted for all four wrong results.
The starter rows moved into a separate exported module, and the tests ran those rows through the calculation model. The date was passed in so the results wouldn’t change depending on which day the tests ran.
The checks were straightforward: the starter cards needed to show their expected values, and a newly provisioned list shouldn’t start a user onboarding with warnings. The missing-date path also needed a warning instead of silently returning a dash.
To check the tests, I put the empty rules back into the seed data. Eight tests failed on the same examples that had been wrong on the page. The tests now caught the missing rules in the starter data.