# Regression tests

A regression test preserves an observable behavior that a change could accidentally break. Start from a minimal case and give it an exact expectation: rows, an error, or a transaction's effect on later reads.

## Make output deterministic

Use an isolated database or a uniquely named test table. Include `ORDER BY` when row order matters and an explicit [output format](https://coordinatordb.com/docs/reference/formats) when comparing text. Use sample values that exercise the reported problem rather than copying production data.

```sql
CREATE TABLE regression_items(id INTEGER PRIMARY KEY, value TEXT);
INSERT INTO regression_items VALUES (2, 'second'), (1, 'first');
SELECT id, value FROM regression_items ORDER BY id FORMAT csv;
```

```text
1,"first"
2,"second"
```

## Test the relevant boundary

An HTTP session test must use separate requests when checking isolation. A native transaction test must keep the same connection when checking commit behavior, then reconnect when checking persistence. See [transactions](https://coordinatordb.com/docs/concepts/features/operations/insert/transactions).

Add an invalid-input case if the change affects validation. Record whether the application receives an error and whether earlier writes remain. Clean up only the data created by the test. Include commands, expected output and interface selection with the contribution so a reviewer can reproduce it.