ShoesSpecConvenience.md

Shoes-Spec Convenience Features

In concept, Shoes-Spec could test basically all of Scarpe, including Niente and Scarpe-Wasm. The current reality falls short.

APIs Behind Features

It would be nice to have a known-in-Shoes-Spec set of HTML APIs locked behind an HTML feature, for instance, and use those in specs. Though checking HTML in specs is somewhat problematic, because you want the specs to be portable, not to hardcode Calzini's current implementation. Still, there are some things you can do, like the tests that check for a color after setting it as fill.

Specifying Expected Results

At a minimum, a spec could give its "ideal" result, whether that's pass, fail or skip and with a minimum or maximum number of assertions completed. But also it should be easy to compare current results to the expected results for a display service, probably without making the spec include a frontmatter entry for every display service. Those would be ugly to keep up to date, especially as display-service versions change. We do not want to have to update the sspec files to switch which version of Scarpe we're testing against. Ew.

## APIs

We should have a "run this code on the Shoes::App" API call. Including action buttons and then triggering them -- when you're not actually testing button-click, anyway -- is pretty silly.

We need APIs for finding and dismissing alert dialogs.