원클릭으로
testing
// How to write tests, when to use each type of test, and how to run them. Contains information about conversion of `.test` to `.sqltest`, and how to write `.sqltest` and rust tests
// How to write tests, when to use each type of test, and how to run them. Contains information about conversion of `.test` to `.sqltest`, and how to write `.sqltest` and rust tests
Use when migrating Turso core code to crate::alloc, allocator-api2, cfg(nightly) allocator aliases, fallible collection APIs, try_vec!, try_collect, or LimboError::OutOfMemory handling. Covers import style, allocator-aware aliases, stable/nightly boundaries, shuttle Arc compatibility, and how to keep allocator foundation commits separate from module migrations.
How to benchmark and analyze memory usage in Turso using the memory-benchmark crate and dhat heap profiler. Use this skill whenever the user mentions memory usage, memory profiling, allocation tracking, heap analysis, memory regression, memory benchmarking, dhat, or wants to understand where memory is being allocated during SQL workloads. Also use when investigating memory growth in WAL or MVCC mode. IMPORTANT - If you modify the perf/memory crate (add profiles, change CLI flags, change output format, etc.), update this skill document to reflect those changes so it stays accurate for future agents.
General Correctness rules, Rust patterns, comments, avoiding over-engineering. When writing code always take these into account
Overview of Experimental MVCC feature - snapshot isolation, versioning, limitations
Change Data Capture - architecture, entrypoints, bytecode emission, sync engine integration, tests
Information about the differential fuzzer tool, how to run it and use it catch bugs in Turso. Always load this skill when running this tool
| name | testing |
| description | How to write tests, when to use each type of test, and how to run them. Contains information about conversion of `.test` to `.sqltest`, and how to write `.sqltest` and rust tests |
| Type | Location | Use Case |
|---|---|---|
.sqltest | testing/sqltests/tests/ | SQL compatibility. Preferred for new tests |
TCL .test | testing/ | Legacy SQL compat (being phased out) |
| Rust integration | tests/integration/ | Regression tests, complex scenarios |
| Fuzz | tests/fuzz/ | Complex features, edge case discovery |
Note: TCL tests are being phased out in favor of testing/sqltests. The .sqltest format allows the same test cases to run against multiple backends (CLI, Rust bindings, etc.).
# Main test suite (TCL compat, sqlite3 compat, Python wrappers)
make test
# Single TCL test
make test-single TEST=select.test
# SQL test runner
make -C testing/sqltests run-cli
# OR
cargo run -p test-runner -- run <test-file or directory>
# Rust unit/integration tests (full workspace)
cargo test
@database :default:
test example-addition {
SELECT 1 + 1;
}
expect {
2
}
test example-multiple-rows {
SELECT id, name FROM users WHERE id < 3;
}
expect {
1|alice
2|bob
}
Location: testing/sqltests/tests/*.sqltest
You must start converting TCL tests with the convert command from the test runner (e.g cargo run -- convert <TCL_test_path> -o <out_dir>). It is not always accurate, but it will convert most of the tests. If some conversion emits a warning you will have to write by hand whatever is missing from it (e.g unroll a for each loop by hand). Then you need to verify the tests work by running them with make -C testing/sqltests run-rust, and adjust their output if something was wrong with the conversion. Also, we use harcoded databases in TCL, but with .sqltest we generate the database with a different seed, so you will probably need to change the expected test result to match the new database query output. Avoid changing the SQL statements from the test, just change the expected result
do_execsql_test_on_specific_db {:memory:} test-name {
SELECT 1 + 1;
} {2}
Location: testing/*.test
// tests/integration/test_foo.rs
#[test]
fn test_something() {
let conn = Connection::open_in_memory().unwrap();
// ...
}
:memory: (sqltest) or {:memory:} (TCL)testing/system/testing.db has users and products tables. See docs/testing.md for schema.
RUST_LOG=none,turso_core=trace make test
Output: testing/system/test.log. Warning: very verbose.