-
Notifications
You must be signed in to change notification settings - Fork 29
ShoesSpecConvenience.md
In concept, Shoes-Spec could test basically all of Scarpe, including Niente and Scarpe-Wasm. The current reality falls short.
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.
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.
Right now there's a fair bit of code in the Shoes-Spec repo to run batches of sspecs against each display lib. That's kind of silly -- that functionality should be in the display lib and Shoes-Spec should just use it. A huge example is for Scarpe-Wasm, where it does an optimised run where it packages Scarpe-Wasm once and then runs all the tests. That should be available in Scarpe-Wasm somehow.
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.