Skip to content

Commit d36f9a6

Browse files
committed
Unit test improvements
1 parent 9687a56 commit d36f9a6

File tree

1 file changed

+11
-5
lines changed

1 file changed

+11
-5
lines changed

AGENTS.md

Lines changed: 11 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -10,14 +10,20 @@
1010
2. Make targeted code changes and refrain from refactoring, unless it's absolutely required.
1111

1212
## Unit Tests Guidelines
13+
- New unit tests should be added to the `tests` module in the corresponding dialect file (e.g., `tests/sqlparser_redshift.rs` for Redshift), and should be placed at the end of the file.
14+
- If the new functionality is gated using a dialect function, and the SQL is likely relevant in most dialects, tests should be placed under `tests/sqlparser_common.rs`.
1315
- When testing a multi-line SQL statement, use a raw string literal, i.e. `r#"..."#` to preserve formatting.
14-
- You can use the following template for simple unit tests:
16+
- The parser builds an abstract syntax tree (AST) from the SQL statement and has functionality to display the tree as SQL. Use the following template for simple unit tests where you expect the SQL created from the AST to be the same as the input SQL:
1517
```rust
16-
<dialect>().parse_sql_statements(r#"..."#).unwrap();
18+
<dialect>().verified_stmt(r#"..."#);
19+
```
20+
For example: `snowflake().verified_stmt(r#"SELECT * FROM my_table"#)`. Use `one_statement_parses_to` instead of `verified_stmt` when you expect the SQL created by the AST to differ than the input SQL. For example:
21+
```rust
22+
snowflake().one_statement_parses_to(
23+
"SELECT * FROM my_table t",
24+
"SELECT * FROM my_table AS t",
25+
)
1726
```
18-
For example: `snowflake().parse_sql_statements(r#"SELECT * FROM my_table"#).unwrap();`
19-
- New unit tests should be added to the `tests` module in the corresponding dialect file (e.g., `tests/sqlparser_redshift.rs` for Redshift), and should be placed at the end of the file.
20-
- If the new functionality is gated using a dialect function, and the SQL is likely relevant in most dialects, tests should be placed under `tests/sqlparser_common.rs`.
2127

2228
## Analyzing Parsing Issues
2329
You can try to simplify the SQL statement to identify the root cause of the parsing issue. This may involve removing certain clauses or components of the SQL statement to see if it can be parsed successfully. Additionally, you can compare the problematic SQL statement with similar statements that are parsed correctly to identify any differences that may be causing the issue.

0 commit comments

Comments
 (0)