mirror of
https://github.com/supabase/supabase.git
synced 2026-10-05 09:25:06 +03:00
Miranda LimonczenkoandNik Richers
801244463a
Closes DOCS-875 **Before:** <img width="1465" height="755" alt="Screenshot 2026-06-17 at 2 19 31 PM" src="https://github.com/user-attachments/assets/5768e7d5-0ef9-43a3-8223-e28b340b3c08" /> **Caption:** "Errors" at the bottom of the screen is just as large as the title. The right sidebar shows h3s. Source: https://supabase.com/docs/guides/database/prisma/prisma-troubleshooting#solution-server-has-closed-the-connection **After:** <img width="1409" height="750" alt="Screenshot 2026-06-17 at 2 20 44 PM" src="https://github.com/user-attachments/assets/e39c797c-5b1f-4fce-a1a6-b3eff9e65f18" /> **Caption:** The "Errors" at the bottom of the screen is smaller than the main h1. The right drops the "Solutions" headers. Source: https://docs-git-demote-h1s-in-body-docs-supabase.vercel.app/docs/guides/database/prisma/prisma-troubleshooting#solution-server-has-closed-the-connection ## I have read the [CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md) file. YES ## Problem The `title` frontmatter generates an `h1`. However, several pages have multiple h1s. ## Fix This PR demotes pages with h1s in the markdown body to h2s and so on. See [a troubleshooting page in production](https://supabase.com/docs/guides/troubleshooting/supabase--your-network-ipv4-and-ipv6-compatibility-cHe3BP) and in [in preview](https://docs-git-demote-h1s-in-body-docs-supabase.vercel.app/docs/guides/troubleshooting/supabase--your-network-ipv4-and-ipv6-compatibility-cHe3BP). ## Future improvements Possibly, we can add a linting rule to prevent this in the future. We'd also want to check that the heading hierarchy is always consistent. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit ## Summary by CodeRabbit * **Documentation** * Updated multiple guides and troubleshooting articles to enforce consistent heading hierarchy and improved section nesting for clearer in-page structure. * Refreshed troubleshooting pages with cleaner table of contents and navigation, including added guide links and re-leveled subsections. * Reformatted Prisma troubleshooting content (including a deprecated redirect) without changing the underlying guidance. * Added a warning about manually setting database connection limits and adjusted related warning/formatting across the max-connections guide. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Nik Richers <nrichers@gmail.com>
77 lines
2.1 KiB
Plaintext
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/)
|