From 60a935139bfb48c384b1f64d8a2e68ac36f69b89 Mon Sep 17 00:00:00 2001 From: Amaan Qureshi Date: Wed, 28 Feb 2024 08:04:40 -0500 Subject: [PATCH] refactor!: remove top-level `corpus` dir for tests It's confusing to have tests in two different top-level directories when working between different grammars, and most of them use `test/corpus` which is more fitting, so time to go. --- cli/src/main.rs | 7 ++----- docs/section-3-creating-parsers.md | 8 ++++---- 2 files changed, 6 insertions(+), 9 deletions(-) diff --git a/cli/src/main.rs b/cli/src/main.rs index 05a85574..c46d38d7 100644 --- a/cli/src/main.rs +++ b/cli/src/main.rs @@ -564,11 +564,8 @@ fn run() -> Result<()> { let test_dir = current_dir.join("test"); - // Run the corpus tests. Look for them at two paths: `test/corpus` and `corpus`. - let mut test_corpus_dir = test_dir.join("corpus"); - if !test_corpus_dir.is_dir() { - test_corpus_dir = current_dir.join("corpus"); - } + // Run the corpus tests. Look for them in `test/corpus`. + let test_corpus_dir = test_dir.join("corpus"); if test_corpus_dir.is_dir() { let mut opts = TestOptions { path: test_corpus_dir, diff --git a/docs/section-3-creating-parsers.md b/docs/section-3-creating-parsers.md index f5636ec9..56e3d9be 100644 --- a/docs/section-3-creating-parsers.md +++ b/docs/section-3-creating-parsers.md @@ -152,7 +152,7 @@ If there is an ambiguity or *local ambiguity* in your grammar, Tree-sitter will The `tree-sitter test` command allows you to easily test that your parser is working correctly. -For each rule that you add to the grammar, you should first create a *test* that describes how the syntax trees should look when parsing that rule. These tests are written using specially-formatted text files in the `corpus/` or `test/corpus/` directories within your parser's root folder. +For each rule that you add to the grammar, you should first create a *test* that describes how the syntax trees should look when parsing that rule. These tests are written using specially-formatted text files in the `test/corpus/` directory within your parser's root folder. For example, you might have a file called `test/corpus/statements.txt` that contains a series of entries like this: @@ -214,13 +214,13 @@ increment(n) == n + 1 These tests are important. They serve as the parser's API documentation, and they can be run every time you change the grammar to verify that everything still parses correctly. -By default, the `tree-sitter test` command runs all of the tests in your `corpus` or `test/corpus/` folder. To run a particular test, you can use the `-f` flag: +By default, the `tree-sitter test` command runs all of the tests in your `test/corpus/` folder. To run a particular test, you can use the `-f` flag: ```sh tree-sitter test -f 'Return statements' ``` -The recommendation is to be comprehensive in adding tests. If it's a visible node, add it to a test file in your `corpus` directory. It's typically a good idea to test all of the permutations of each language construct. This increases test coverage, but doubly acquaints readers with a way to examine expected outputs and understand the "edges" of a language. +The recommendation is to be comprehensive in adding tests. If it's a visible node, add it to a test file in your `test/corpus` directory. It's typically a good idea to test all of the permutations of each language construct. This increases test coverage, but doubly acquaints readers with a way to examine expected outputs and understand the "edges" of a language. #### Automatic Compilation @@ -419,7 +419,7 @@ With this structure in place, you can now freely decide what part of the grammar After developing the *type* sublanguage a bit further, you might decide to switch to working on *statements* or *expressions* instead. It's often useful to check your progress by trying to parse some real code using `tree-sitter parse`. -**And remember to add tests for each rule in your `corpus` folder!** +**And remember to add tests for each rule in your `test/corpus` folder!** ### Structuring Rules Well