Checking a page
A page you have just written has no tests yet. assay opens it in a real
browser, finds every control on it, uses all of them, and reports what it did
and what happened.
When to run it
When the work is done, not while you are still making changes. Run it once
at the end, after the last edit, on each page you changed.
That includes changes to the JavaScript or CSS a page loads, not only the
HTML. The page is often a folder or two above the file you changed.
Run exactly this
assay <the page you changed> --one-line
Point it at the page itself, such as todo.html or dist/index.html. A
folder works too and opens the index.html inside it. It needs no key or
configuration. The first run downloads Chromium if it isn't installed yet. A
small page takes seconds, and a busy one can take a minute or more.
Then print what it printed
Put its output, verbatim, as the last thing in your reply. It is already
one line, or one line and a short list. Do not summarise it, reformat it, add
to it, or write your own version.
It looks like this, and the numbers and wording are assay's own:
assay: checked <page>, <n> checks, nothing flagged.
Print it whether it flagged anything or not. If you print nothing, the reader
can't tell a clean page from a check that never ran.
If the command did not run, say so instead, in your own words, naming the
page and quoting what the shell actually said. Never describe a check that did
not happen as one that passed, and never guess at a cause. If the shell printed
an error, quote it. If you didn't see one, say only that it did not run.
Do not act on what it found
Report it and stop. Do not edit code in response to a finding in the same
reply.
assay doesn't know what the page is for. It presses what the page offers and
reports what followed, so a finding is a place to look, not a confirmed bug. A
control can correctly do nothing in the state it was pressed in, and a value
can be limited on purpose. Changing working code because of a finding nobody
has checked is the mistake to avoid, which is why you report instead of
fixing.
If the person you are working with asks you to fix it, then fix it.
What it will not do
- It will not build your project. Point it at built output. Given a source
tree, it says so and names the command to run. It won't run
npm install
for you, because installing dependencies executes their setup scripts.
- It checks one page. It doesn't crawl, so run it on each page.
- It can't check intent. A control that runs but does the wrong thing
usually isn't caught.