Mirrors/rust-analyzer
2
0
Fork 0
mirror of https://github.com/rust-lang/rust-analyzer synced 2024-12-26 04:53:34 +00:00
Code Issues Projects Releases Packages Wiki Activity

Merge #4835

Browse source 
4835: Explain inline tests r=matklad a=matklad



bors r+
🤖

Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
This commit is contained in:
bors[bot] 2020-06-10 12:12:32 +00:00 committed by GitHub
commit 96309ba4a1
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
1 changed files with 11 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

11
docs/dev/README.md
View file

@ -303,6 +303,17 @@ Rather than talking in definitions and references, it talks in Strings and textu
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.
The results are 100% Rust specific though.
## Parser Tests
Test for parser (`ra_parser`) live in `ra_syntax` crate (see `test_data` direcotory).
There are two kinds of tests:
* Manually written test cases in `parser/ok` and `parser/error`
* "Inline" tests in `parser/inline` (these are generated) from comments in `ra_parser` crate.
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.
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.
# Logging
Logging is done by both rust-analyzer and VS Code, so it might be tricky to