You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
| `FILTER_CRATE` | `string` | Only include results from the given crate. In the GUI, this is the "Results in <kbd>crate</kbd>" drop-down menu.
378
+
| `EXPECTED` | `[ResultsTable]\|ResultsTable` | List of tests to run, specifying what the hypothetical user types into the search box and sees in the tabs
379
+
| `PARSED` | `[ParsedQuery]\|ParsedQuery` | List of parser tests to run, without running an actual search
380
+
381
+
Additionally, the following magic comments are supported.
382
+
Put them on their own line, without indenting.
383
+
384
+
*`// exact-check`: If search results appear that aren't part of the test case,
385
+
then fail. By default, the test case will tolerate the engine returning more
386
+
results than specified.
387
+
*`// ignore-order`: By default, the entries in the test case must have a
388
+
matching order in the results. Setting this option allows you to test
389
+
filtering without also testing ranking, if you expect a test to be sensitive
390
+
to minor scoring changes.
391
+
*`// should-fail`: Used to write negative tests.
392
+
393
+
Standard library tests probably shouldn't specify any of these (we want the
394
+
libs team to be able to add new stuff without causing our tests to fail), but
395
+
standalone tests will often want `// exact-check`.
396
+
397
+
`FILTER_CRATE` can be left out (equivalent to searching "all crates"), but you
398
+
have to specify `EXPECTED` or `PARSED`.
399
+
400
+
The `ResultsTable` and `ParsedQuery` types are specified in
0 commit comments