home / skills / tursodatabase / turso / testing

testing skill

/.claude/skills/testing

This skill guides you in writing and running tests across .sqltest and Rust, enabling reliable SQL compatibility and regression coverage.

npx playbooks add skill tursodatabase/turso --skill testing

Review the files below or copy the command above to add this skill to your agents.

Files (1)
SKILL.md
3.0 KB
---
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
---
# Testing Guide

## Test Types & When to Use

| Type | Location | Use Case |
|------|----------|----------|
| `.sqltest` | `testing/runner/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/runner. The `.sqltest` format allows the same test cases to run against multiple backends (CLI, Rust bindings, etc.).

## Running Tests

```bash
# 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/runner run-cli

# OR
cargo run -p test-runner -- run <test-file or directory>

# Rust unit/integration tests (full workspace)
cargo test
```

## Writing Tests

### .sqltest (Preferred)
```
@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/runner/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/runner 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 

### TCL
```tcl
do_execsql_test_on_specific_db {:memory:} test-name {
  SELECT 1 + 1;
} {2}
```
Location: `testing/*.test`

### Rust Integration
```rust
// tests/integration/test_foo.rs
#[test]
fn test_something() {
    let conn = Connection::open_in_memory().unwrap();
    // ...
}
```

## Key Rules

- Every functional change needs a test
- Test must fail without change, pass with it
- Prefer in-memory DBs: `:memory:` (sqltest) or `{:memory:}` (TCL)
- Don't invent new test formats. Follow existing patterns
- Write tests first when possible

## Test Database Schema

`testing/system/testing.db` has `users` and `products` tables. See [docs/testing.md](../../../docs/testing.md) for schema.

## Logging During Tests

```bash
RUST_LOG=none,turso_core=trace make test
```
Output: `testing/system/test.log`. Warning: very verbose.

Overview

This skill explains how to write and run tests for Turso, when to use each test type, and how to convert legacy TCL tests into the preferred .sqltest format. It focuses on practical commands, file locations, and concrete rules so tests reliably catch regressions across CLI, Rust bindings, and other backends. The guidance covers .sqltest syntax, conversion tips, and Rust integration tests.

How this skill works

The skill describes the test types (.sqltest, legacy TCL .test, Rust integration, and fuzz) and where they live in the project. It shows how the test runner executes .sqltest files across multiple backends and how to run the test runner or cargo test locally. It also explains converting TCL tests to .sqltest, verifying converted outputs, and adjusting expectations when database seeds differ.

When to use it

  • Use .sqltest for new SQL compatibility tests and cross-backend execution.
  • Use TCL .test only for legacy cases during conversion; do not create new TCL tests.
  • Use Rust integration tests for complex scenarios and regressions requiring programmatic setup.
  • Use fuzzing for edge-case discovery and complex feature stress tests.
  • Run cargo test for unit/integration Rust tests across the workspace.

Best practices

  • Prefer .sqltest for new tests and place them in testing/runner/tests/*.sqltest.
  • Start with failing tests: write tests before implementing changes when possible.
  • Use in-memory databases (:memory: for .sqltest, {:memory:} for TCL) to keep tests fast and deterministic.
  • When converting TCL tests, run the test-runner convert command and manually fix warnings; don’t change SQL statements—adjust expected output instead.
  • Keep tests small and focused: each test should verify one behavior and fail without the intended change.

Example use cases

  • Add a SQL compatibility test that asserts a query returns specific rows using a .sqltest file.
  • Convert a legacy TCL test by running the test-runner convert command, then run make -C testing/runner run-rust to validate and fix expected output.
  • Write a Rust integration test to exercise complex transaction behavior not easily expressed in .sqltest.
  • Run the full test matrix with make test or run a single TCL test with make test-single TEST=select.test.
  • Enable detailed logs for a failing test with RUST_LOG=none,turso_core=trace make test and inspect testing/system/test.log.

FAQ

How do I convert a TCL .test to .sqltest?

Run cargo run -p test-runner -- convert <TCL_test_path> -o <out_dir>. Inspect warnings, manually fix any unconverted constructs, then run make -C testing/runner run-rust to validate and adjust expected output.

Why do expected outputs change after conversion?

The .sqltest runner generates databases with different seeds than the hardcoded TCL databases, so row ordering or generated IDs can differ; don’t change SQL—update expected results to match the new database output.