Skip to content

Commit af1c98d

Browse files
notriddlecompiler-errors
authored andcommitted
Add docs for JS tests
1 parent d39f68b commit af1c98d

File tree

2 files changed

+101
-1
lines changed

2 files changed

+101
-1
lines changed

src/rustdoc-internals/search.md

+99
Original file line numberDiff line numberDiff line change
@@ -354,3 +354,102 @@ The unification filter ensures that:
354354
The bloom filter checks none of these things,
355355
and, on top of that, can have false positives.
356356
But it's fast and uses very little memory, so the bloom filter helps.
357+
358+
## Testing the search engine
359+
360+
While the DOM UI code itself is tested using `rustdoc-gui` tests, the
361+
primary way the search engine is tested is the `rustdoc-js` and
362+
`rustdoc-js-std` tests. They run in NodeJS.
363+
364+
A `rustdoc-js` test has a `.rs` and `.js` file, with the same name.
365+
The `.rs` file specifies the hypothetical library crate to run
366+
the searches on (make sure you mark anything you need to find as `pub`).
367+
The `.js` file specifies the actual searches.
368+
The `rustdoc-js-std` tests are the same, but don't require an `.rs`
369+
file, since they use the standard library.
370+
371+
The `.js` file is like a module (except the loader takes care of
372+
`exports` for you). It expects you to set these variables in the
373+
module's scope:
374+
375+
| Name | Type | Description
376+
| -------------- | ------------------------------ | -------------------------------------------------------------------------------------------------------------
377+
| `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
401+
[`externs.js`](https://github.com/rust-lang/rust/blob/master/src/librustdoc/html/static/js/externs.js).
402+
403+
For example, imagine we needed to fix a bug where a function named
404+
`constructor` couldn't be found. To do this, write two files:
405+
406+
```rust
407+
// tests/rustdoc-js/constructor_search.rs
408+
// The test case needs to find this result.
409+
pub fn constructor(_input: &str) -> i32 { 1 }
410+
```
411+
412+
```js
413+
// tests/rustdoc-js/constructor_search.js
414+
// exact-check
415+
// Since this test runs against its own crate,
416+
// new items should not appear in the search results.
417+
const EXPECTED = [
418+
// This first test targets name-based search.
419+
{
420+
query: "constructor",
421+
others: [
422+
{ path: "constructor_search", name: "constructor" },
423+
],
424+
in_args: [],
425+
returned: [],
426+
},
427+
// This test targets the second tab.
428+
{
429+
query: "str",
430+
others: [],
431+
in_args: [
432+
{ path: "constructor_search", name: "constructor" },
433+
],
434+
returned: [],
435+
},
436+
// This test targets the third tab.
437+
{
438+
query: "i32",
439+
others: [],
440+
in_args: [],
441+
returned: [
442+
{ path: "constructor_search", name: "constructor" },
443+
],
444+
},
445+
// This test targets advanced type-driven search.
446+
{
447+
query: "str -> i32",
448+
others: [
449+
{ path: "constructor_search", name: "constructor" },
450+
],
451+
in_args: [],
452+
returned: [],
453+
},
454+
]
455+
```

src/rustdoc.md

+2-1
Original file line numberDiff line numberDiff line change
@@ -83,7 +83,8 @@ does is call the `main()` that's in this crate's `lib.rs`, though.)
8383
* All paths in this section are relative to `tests` in the rust-lang/rust repository.
8484
* Tests on search index generation are located in `rustdoc-js`, as a
8585
series of JavaScript files that encode queries on the standard library search
86-
index and expected results.
86+
index and expected results. The format is specified
87+
[in the search guide](rustdoc-internals/search.md#testing-the-search-engine).
8788
* Tests on the "UI" of rustdoc (the terminal output it produces when run) are in
8889
`rustdoc-ui`
8990
* Tests on the "GUI" of rustdoc (the HTML, JS, and CSS as rendered in a browser)

0 commit comments

Comments
 (0)