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

By tursodatabase · 1,171 installs

npx skills add tursodatabase/turso --skill testing

Source repository · Upstream listing

Testing Guide Test Types & When to Use Type Location Use Case .sqltest sqlite/conformance/sqlite sqltests/ 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 the .sqltest suites in sqlite/conformance/ . The .sqltest format allows the same test cases to run against multiple backends (CLI, Rust bindings, etc.). Running Tests Writing Tests .sqltest (Preferred) Location: sqlite/conformance/sqlite sqltests/ .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 sqlite/conformance 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 Location: testing/ .test Rust Integration 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 Output: testing/system/test.log . Warning: very verbose.