Skip to content

Commit 96309ba

Browse files
bors[bot]matklad
andauthored
Merge #4835
4835: Explain inline tests r=matklad a=matklad bors r+ 🤖 Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
2 parents f632727 + 1538206 commit 96309ba

File tree

1 file changed

+11
-0
lines changed

1 file changed

+11
-0
lines changed

docs/dev/README.md

Lines changed: 11 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -303,6 +303,17 @@ Rather than talking in definitions and references, it talks in Strings and textu
303303
In general, API is centered around UI concerns -- the result of the call is what the user sees in the editor, and not what the compiler sees underneath.
304304
The results are 100% Rust specific though.
305305

306+
## Parser Tests
307+
308+
Test for parser (`ra_parser`) live in `ra_syntax` crate (see `test_data` direcotory).
309+
There are two kinds of tests:
310+
311+
* Manually written test cases in `parser/ok` and `parser/error`
312+
* "Inline" tests in `parser/inline` (these are generated) from comments in `ra_parser` crate.
313+
314+
The purpose of inline tests is not to achieve full coverage by test cases, but to explain to the reader of the code what each particular `if` and `match` is responsible for.
315+
If you are tempted to add a large inline test, it might be a good idea to leave only the simplest example in place, and move the test to a manual `parser/ok` test.
316+
306317
# Logging
307318

308319
Logging is done by both rust-analyzer and VS Code, so it might be tricky to

0 commit comments

Comments
 (0)