To find the next test to work on, run:
go run ./cmd/next-testThis tool finds all tests with todo: true in their metadata and returns the one with the shortest query.sql file.
- Run
go run ./cmd/next-testto find the next test to implement - Check the test's
query.sqlto understand what ClickHouse SQL needs parsing - Check the test's
explain.txtto understand the expected EXPLAIN output - Implement the necessary AST types in
ast/ - Add parser logic in
parser/parser.go - Update the
Explain()function if needed to match ClickHouse's output format - Enable the test by removing
todo: truefrom itsmetadata.json(set it to{}) - Run
go test ./parser/... -timeout 5sto verify - Check if other todo tests now pass (see below)
Always run parser tests with a 5 second timeout:
go test ./parser/... -timeout 5sThe tests are very fast. If a test is timing out, it indicates a bug (likely an infinite loop in the parser).
After implementing parser changes, run:
go test ./parser/... -check-skipped -v 2>&1 | grep "PASSES NOW"Tests that output PASSES NOW can have their todo flag removed from metadata.json. This helps identify when parser improvements fix multiple tests at once.
Each test in parser/testdata/ contains:
metadata.json-{}for enabled tests,{"todo": true}for pending testsquery.sql- ClickHouse SQL to parseexplain.txt- Expected EXPLAIN AST output (matches ClickHouse's format)
todo: true- Test is pending implementationskip: true- Skip test entirely (e.g., causes infinite loop)explain: false- Skip test (e.g., ClickHouse couldn't parse it)parse_error: true- Query is intentionally invalid SQL
NEVER modify explain.txt files - These are golden files containing the expected output from ClickHouse. If tests fail due to output mismatches, fix the Go code to match the expected output, not the other way around.