Take the changes to the smoke tests from #344 into their own branch.
We should test every API route, and known values for those API routes, as well as identify passing criteria for those API routes. Currently (on the master branch) our "smoke test" just boots up the server; it's important to verify that the routes we expect to work do work, especially when evaluating the efficacy of PRs like #344 and #447, which would otherwise silently break production.
This'll also give us a canary mechanism for nightly or weekly tests.
@frog-pond/core, I think it might be wise to use Python or something else (maybe even Rust 😉 ?) to combinatorially generate templates (e.g. the Cartesian products of {gzip, no-gzip} x {[various headers]} x {api routes}, etc.) to test during smoke testing. Any opinions on doing that? Obviously we don't want to spam our upstream sources, too, so we might have to cache responses from that.
Take the changes to the smoke tests from #344 into their own branch.
We should test every API route, and known values for those API routes, as well as identify passing criteria for those API routes. Currently (on the
masterbranch) our "smoke test" just boots up the server; it's important to verify that the routes we expect to work do work, especially when evaluating the efficacy of PRs like #344 and #447, which would otherwise silently break production.This'll also give us a canary mechanism for nightly or weekly tests.
@frog-pond/core, I think it might be wise to use Python or something else (maybe even Rust 😉 ?) to combinatorially generate templates (e.g. the Cartesian products of
{gzip, no-gzip}x{[various headers]}x{api routes}, etc.) to test during smoke testing. Any opinions on doing that? Obviously we don't want to spam our upstream sources, too, so we might have to cache responses from that.