Supabase CLI

Testing and linting

Using the CLI to test your Supabase project.

The Supabase CLI provides a set of tools to help you test and lint your Postgres database and Edge` Functions.

Testing your database

The Supabase CLI provides Postgres linting using the supabase test db command.


_10
supabase test db --help
_10
Tests local database with pgTAP
_10
_10
Usage:
_10
supabase test db [flags]

This is powered by the pgTAP extension. You can find a full guide to writing and running tests in the Testing your database section.

Test helpers

Our friends at Basejump have created a useful set of Database Test Helpers, with an accompanying blog post.

Running database tests in CI

Use our GitHub Action to automate your database tests.

Testing your Edge Functions

Edge Functions are powered by Deno, which provides a native set of testing tools. We extend this functionality in the Supabase CLI. You can find a detailed guide in the Edge Functions section.

Testing Auth emails

The Supabase CLI uses Inbucket to capture emails sent from your local machine. This is useful for testing emails sent from Supabase Auth.

Accessing Inbucket

By default, Inbucket is available at localhost:54324 when you run supabase start. Simply open this URL in your browser to view the emails.

Going into production

The "default" email provided by Supabase is only for development purposes. It is heavily restricted to ensure that it is not used for spam. Before going into production, you must configure your own email provider. This is as simple as enabling a new SMTP credentials in your project settings.

Linting your database

The Supabase CLI provides Postgres linting using the supabase db lint command:


_10
supabase db lint --help
_10
Checks local database for typing error
_10
_10
Usage:
_10
supabase db lint [flags]
_10
_10
Flags:
_10
--level [ warning | error ] Error level to emit. (default warning)
_10
--linked Lints the linked project for schema errors.
_10
-s, --schema strings List of schema to include. (default all)

This is powered by plpgsql_check, which leverages the internal Postgres parser/evaluator so you see any errors that would occur at runtime. It provides the following features:

  • validates you are using the correct types for function parameters
  • identifies unused variables and function arguments
  • detection of dead code (any code after an RETURN command)
  • detection of missing RETURN commands with your Postgres function
  • identifies unwanted hidden casts, which can be a performance issue
  • checks EXECUTE statements against SQL injection vulnerability

Check the Reference Docs for more information.