aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorAleksey Kladov <[email protected]>2019-03-20 14:22:22 +0000
committerAleksey Kladov <[email protected]>2019-03-20 14:22:22 +0000
commit86d5c32e4a96dc18ebc3f834ee74d403e4deceba (patch)
tree1964a353ddf41558dc997fa433dc11a52b9b7fa1
parentd56c2f24252d5d444267e33950825f0a7cb438ca (diff)
describe how do we test things
-rw-r--r--docs/dev/architecture.md27
1 files changed, 26 insertions, 1 deletions
diff --git a/docs/dev/architecture.md b/docs/dev/architecture.md
index 3cd63bf73..f990d5bf0 100644
--- a/docs/dev/architecture.md
+++ b/docs/dev/architecture.md
@@ -171,4 +171,29 @@ A CLI interface to rust-analyzer.
171 171
172## Testing Infrastructure 172## Testing Infrastructure
173 173
174 174Rust Analyzer has three interesting [systems
175boundaries](https://www.tedinski.com/2018/04/10/making-tests-a-positive-influence-on-design.html)
176to concentrate tests on.
177
178The outermost boundary is the `ra_lsp_server` crate, which defines an LSP
179interface in terms of stdio. We do integration testing of this component, by
180feeding it with a stream of LSP requests and checking responses. These tests are
181known as "heavy", because they interact with Cargo and read real files from
182disk. For this reason, we try to avoid writing too many tests on this boundary:
183in a statically typed language, it's hard to make an error in the protocol
184itself if messages are themselves typed.
185
186The middle, and most important, boundary is `ra_ide_api`. Unlike
187`ra_lsp_server`, which exposes API, `ide_api` uses Rust API and is intended to
188use by various tools. Typical test creates an `AnalysisHost`, calls some
189`Analysis` functions and compares the results against expectation.
190
191The innermost and most elaborate boundary is `hir`. It has a much richer
192vocabulary of types than `ide_api`, but the basic testing setup is the same: we
193create a database, run some queries, assert result.
194
195For comparisons, we use [insta](https://github.com/mitsuhiko/insta/) library for
196snapshot testing.
197
198To test various analysis corner cases and avoid forgetting about old tests, we
199use so-called marks. See the `marks` module in the `test_utils` crate for more.