Files
supabase/apps/docs/content/guides/database/testing.mdx
T
608040b8cb chore(docs) Resolve 'simple' style warnings where applicable (#46966)
Contributes to DOCS-1052

## I have read the
[CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md)
file.

YES

## What kind of change does this PR introduce?

Resolves MDX linting errors related to "simple" where it applies.
There was a couple cases that did not apply. For example, a product with
"Simple" in the name.

These changes are made in context, either by removing or using a more
descriptive synonym like "minimal" or "basic".

## Tophatting

1. Read each of the diffs.
2. See that the text still makes sense in context.

For extra due diligence, you can run `pnpm lint:mdx` locally and see the
'simple' errors that remain and whether they are worth addressing.


<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit

## Summary by CodeRabbit

* **Documentation**
* Updated many guide, tutorial, and troubleshooting pages with clearer
“basic”/“minimal” wording across setup steps, local testing
instructions, security cautions, and RLS guidance.
* Refined headings, example descriptions, and inline comments for
consistency (including deployment, MCP, metrics API, and search/function
phrasing).
* Improved readability with small snippet formatting tweaks (whitespace
plus import/comment ordering) and added a self-hosting debugging note
for Envoy admin endpoints via a short-lived `curl` container.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->

---------

Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
Co-authored-by: Chris Chinchilla <chris.ward@supabase.io>
Co-authored-by: Nik Richers <nrichers@gmail.com>
2026-06-16 21:45:55 +00:00

77 lines
2.1 KiB
Plaintext

---
id: 'testing'
title: 'Testing Your Database'
description: 'Test your database schema, tables, functions, and policies.'
---
To ensure that queries return the expected data, RLS policies are correctly applied and etc., we encourage you to write automated tests. There are essentially two approaches to testing:
- Firstly, you can write tests that interface with a Supabase client instance (same way you use Supabase client in your application code) in the programming language(s) you use in your application and using your favorite testing framework.
- Secondly, you can test through the Supabase CLI, which is a more low-level approach where you write tests in SQL.
# Testing using the Supabase CLI
You can use the Supabase CLI to test your database. The minimum required version of the CLI is [v1.11.4](https://github.com/supabase/cli/releases). To get started:
- [Install the Supabase CLI](/docs/guides/cli) on your local machine
## Creating a test
Create a tests folder inside the `supabase` folder:
```bash
mkdir -p ./supabase/tests/database
```
Create a new file with the `.sql` extension which will contain the test.
```bash
touch ./supabase/tests/database/hello_world.test.sql
```
## Writing tests
All `sql` files use [pgTAP](/docs/guides/database/extensions/pgtap) as the test runner.
Write a test to check that our `auth.users` table has an ID column. Open `hello_world.test.sql` and add the following code:
```sql
begin;
select plan(1); -- only one statement to run
SELECT has_column(
'auth',
'users',
'id',
'id should exist'
);
select * from finish();
rollback;
```
## Running tests
To run the test, you can use:
```bash
supabase test db
```
This will produce the following output:
```bash
$ supabase test db
supabase/tests/database/hello_world.test.sql .. ok
All tests successful.
Files=1, Tests=1, 1 wallclock secs ( 0.01 usr 0.00 sys + 0.04 cusr 0.02 csys = 0.07 CPU)
Result: PASS
```
## More resources
- [Testing RLS policies](/docs/guides/database/extensions/pgtap#testing-rls-policies)
- [pgTAP extension](/docs/guides/database/extensions/pgtap)
- Official [pgTAP documentation](https://pgtap.org/)