supabase-test 0.0.6 → 0.0.8
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +411 -59
- package/package.json +3 -3
package/README.md
CHANGED
|
@@ -1,7 +1,7 @@
|
|
|
1
1
|
# supabase-test
|
|
2
2
|
|
|
3
3
|
<p align="center" width="100%">
|
|
4
|
-
<img height="250" src="https://raw.githubusercontent.com/launchql/launchql/refs/heads/main/assets/
|
|
4
|
+
<img height="250" src="https://raw.githubusercontent.com/launchql/launchql/refs/heads/main/assets/supatest.svg" />
|
|
5
5
|
</p>
|
|
6
6
|
|
|
7
7
|
<p align="center" width="100%">
|
|
@@ -11,9 +11,12 @@
|
|
|
11
11
|
<a href="https://github.com/launchql/launchql/blob/main/LICENSE">
|
|
12
12
|
<img height="20" src="https://img.shields.io/badge/license-MIT-blue.svg"/>
|
|
13
13
|
</a>
|
|
14
|
+
<a href="https://www.npmjs.com/package/supabase-test">
|
|
15
|
+
<img height="20" src="https://img.shields.io/github/package-json/v/launchql/launchql?filename=packages%2Fsupabase-test%2Fpackage.json"/>
|
|
16
|
+
</a>
|
|
14
17
|
</p>
|
|
15
18
|
|
|
16
|
-
`supabase-test` is a Supabase-optimized version of `pgsql-test` with Supabase defaults baked in. It provides instant, isolated PostgreSQL databases for testing with automatic transaction rollbacks, context switching, and clean seeding — configured for Supabase's local development environment.
|
|
19
|
+
`supabase-test` is a Supabase-optimized version of [`pgsql-test`](https://www.npmjs.com/package/pgsql-test) with Supabase defaults baked in. It provides instant, isolated PostgreSQL databases for testing with automatic transaction rollbacks, context switching, and clean seeding — configured for Supabase's local development environment. It's also great for GitHub Actions and CI/CD testing.
|
|
17
20
|
|
|
18
21
|
## Install
|
|
19
22
|
|
|
@@ -29,19 +32,37 @@ npm install supabase-test
|
|
|
29
32
|
* 🌱 **Flexible seeding** — run `.sql` files, programmatic seeds, or even load fixtures
|
|
30
33
|
* 🧪 **Compatible with any async runner** — works with `Jest`, `Mocha`, etc.
|
|
31
34
|
* 🧹 **Auto teardown** — no residue, no reboots, just clean exits
|
|
32
|
-
* 🎯 **Supabase defaults** — pre-configured for Supabase local development (port 54322, `supabase_admin` user)
|
|
33
35
|
|
|
34
|
-
|
|
36
|
+
### LaunchQL migrations
|
|
37
|
+
|
|
38
|
+
Part of the [LaunchQL](https://github.com/launchql) ecosystem, `pgsql-test` is built to pair seamlessly with our TypeScript-based [Sqitch](https://sqitch.org/) engine rewrite:
|
|
39
|
+
|
|
40
|
+
* 🚀 **Lightning-fast migrations** — powered by LaunchQL’s native deployer (10x faster than legacy Sqitch)
|
|
41
|
+
* 🔧 **Composable test scaffolds** — integrate with full LaunchQL stacks or use standalone
|
|
35
42
|
|
|
36
|
-
This package automatically uses Supabase's local development defaults:
|
|
37
43
|
|
|
38
|
-
|
|
39
|
-
* **User:** `supabase_admin`
|
|
40
|
-
* **Password:** `postgres`
|
|
44
|
+
## Table of Contents
|
|
41
45
|
|
|
42
|
-
|
|
46
|
+
1. [Install](#install)
|
|
47
|
+
2. [Features](#features)
|
|
48
|
+
3. [Quick Start](#-quick-start)
|
|
49
|
+
4. [`getConnections()` Overview](#getconnections-overview)
|
|
50
|
+
5. [PgTestClient API Overview](#pgtestclient-api-overview)
|
|
51
|
+
6. [Usage Examples](#usage-examples)
|
|
52
|
+
* [Basic Setup](#-basic-setup)
|
|
53
|
+
* [Role-Based Context](#-role-based-context)
|
|
54
|
+
* [Seeding System](#-seeding-system)
|
|
55
|
+
* [SQL File Seeding](#-sql-file-seeding)
|
|
56
|
+
* [Programmatic Seeding](#-programmatic-seeding)
|
|
57
|
+
* [CSV Seeding](#️-csv-seeding)
|
|
58
|
+
* [JSON Seeding](#️-json-seeding)
|
|
59
|
+
* [Sqitch Seeding](#️-sqitch-seeding)
|
|
60
|
+
* [LaunchQL Seeding](#-launchql-seeding)
|
|
61
|
+
7. [`getConnections() Options` ](#getconnections-options)
|
|
62
|
+
8. [Disclaimer](#disclaimer)
|
|
43
63
|
|
|
44
|
-
|
|
64
|
+
|
|
65
|
+
## ✨ Quick Start
|
|
45
66
|
|
|
46
67
|
```ts
|
|
47
68
|
import { getConnections } from 'supabase-test';
|
|
@@ -54,30 +75,93 @@ beforeAll(async () => {
|
|
|
54
75
|
});
|
|
55
76
|
|
|
56
77
|
afterAll(() => teardown());
|
|
57
|
-
beforeEach(() => db.beforeEach());
|
|
58
|
-
afterEach(() => db.afterEach());
|
|
59
78
|
```
|
|
60
79
|
|
|
61
|
-
##
|
|
80
|
+
## `getConnections()` Overview
|
|
81
|
+
|
|
82
|
+
```ts
|
|
83
|
+
import { getConnections } from 'supabase-test';
|
|
84
|
+
|
|
85
|
+
// Complete object destructuring
|
|
86
|
+
const { pg, db, admin, teardown, manager } = await getConnections();
|
|
87
|
+
|
|
88
|
+
// Most common pattern
|
|
89
|
+
const { db, teardown } = await getConnections();
|
|
90
|
+
```
|
|
91
|
+
|
|
92
|
+
The `getConnections()` helper sets up a fresh PostgreSQL test database and returns a structured object with:
|
|
93
|
+
|
|
94
|
+
* `pg`: a `PgTestClient` connected as the root or superuser — useful for administrative setup or introspection
|
|
95
|
+
* `db`: a `PgTestClient` connected as the app-level user — used for running tests with RLS and granted permissions
|
|
96
|
+
* `admin`: a `DbAdmin` utility for managing database state, extensions, roles, and templates
|
|
97
|
+
* `teardown()`: a function that shuts down the test environment and database pool
|
|
98
|
+
* `manager`: a shared connection pool manager (`PgTestConnector`) behind both clients
|
|
62
99
|
|
|
63
|
-
|
|
100
|
+
Together, these allow fast, isolated, role-aware test environments with per-test rollback and full control over setup and teardown.
|
|
101
|
+
|
|
102
|
+
The `PgTestClient` returned by `getConnections()` is a fully-featured wrapper around `pg.Pool`. It provides:
|
|
103
|
+
|
|
104
|
+
* Automatic transaction and savepoint management for test isolation
|
|
105
|
+
* Easy switching of role-based contexts for RLS testing
|
|
106
|
+
* A clean, high-level API for integration testing PostgreSQL systems
|
|
107
|
+
|
|
108
|
+
## `PgTestClient` API Overview
|
|
109
|
+
|
|
110
|
+
```ts
|
|
111
|
+
let pg: PgTestClient;
|
|
112
|
+
let teardown: () => Promise<void>;
|
|
113
|
+
|
|
114
|
+
beforeAll(async () => {
|
|
115
|
+
({ pg, teardown } = await getConnections());
|
|
116
|
+
});
|
|
117
|
+
|
|
118
|
+
beforeEach(() => pg.beforeEach());
|
|
119
|
+
afterEach(() => pg.afterEach());
|
|
120
|
+
afterAll(() => teardown());
|
|
121
|
+
```
|
|
122
|
+
|
|
123
|
+
The `PgTestClient` returned by `getConnections()` wraps a `pg.Client` and provides convenient helpers for query execution, test isolation, and context switching.
|
|
124
|
+
|
|
125
|
+
### Common Methods
|
|
126
|
+
|
|
127
|
+
* `query(sql, values?)` – Run a raw SQL query and get the `QueryResult`
|
|
128
|
+
* `beforeEach()` – Begins a transaction and sets a savepoint (called at the start of each test)
|
|
129
|
+
* `afterEach()` – Rolls back to the savepoint and commits the outer transaction (cleans up test state)
|
|
130
|
+
* `setContext({ key: value })` – Sets PostgreSQL config variables (like `role`) to simulate RLS contexts
|
|
131
|
+
* `any`, `one`, `oneOrNone`, `many`, `manyOrNone`, `none`, `result` – Typed query helpers for specific result expectations
|
|
132
|
+
|
|
133
|
+
These methods make it easier to build expressive and isolated integration tests with strong typing and error handling.
|
|
134
|
+
|
|
135
|
+
The `PgTestClient` returned by `getConnections()` is a fully-featured wrapper around `pg.Pool`. It provides:
|
|
136
|
+
|
|
137
|
+
* Automatic transaction and savepoint management for test isolation
|
|
138
|
+
* Easy switching of role-based contexts for RLS testing
|
|
139
|
+
* A clean, high-level API for integration testing PostgreSQL systems
|
|
140
|
+
|
|
141
|
+
## Usage Examples
|
|
142
|
+
|
|
143
|
+
### ⚡ Basic Setup
|
|
64
144
|
|
|
65
145
|
```ts
|
|
66
146
|
import { getConnections } from 'supabase-test';
|
|
67
147
|
|
|
68
|
-
let db
|
|
148
|
+
let db; // A fully wrapped PgTestClient using pg.Pool with savepoint-based rollback per test
|
|
149
|
+
let teardown;
|
|
69
150
|
|
|
70
151
|
beforeAll(async () => {
|
|
71
152
|
({ db, teardown } = await getConnections());
|
|
72
|
-
|
|
73
|
-
// Setup schema
|
|
153
|
+
|
|
74
154
|
await db.query(`
|
|
75
155
|
CREATE TABLE users (id SERIAL PRIMARY KEY, name TEXT);
|
|
156
|
+
CREATE TABLE posts (id SERIAL PRIMARY KEY, user_id INT REFERENCES users(id), content TEXT);
|
|
157
|
+
|
|
76
158
|
INSERT INTO users (name) VALUES ('Alice'), ('Bob');
|
|
159
|
+
INSERT INTO posts (user_id, content) VALUES (1, 'Hello world!'), (2, 'Graphile is cool!');
|
|
77
160
|
`);
|
|
78
161
|
});
|
|
79
162
|
|
|
80
163
|
afterAll(() => teardown());
|
|
164
|
+
|
|
81
165
|
beforeEach(() => db.beforeEach());
|
|
82
166
|
afterEach(() => db.afterEach());
|
|
83
167
|
|
|
@@ -87,77 +171,344 @@ test('user count starts at 2', async () => {
|
|
|
87
171
|
});
|
|
88
172
|
```
|
|
89
173
|
|
|
90
|
-
###
|
|
174
|
+
### 🔐 Role-Based Context
|
|
175
|
+
|
|
91
176
|
|
|
92
|
-
|
|
177
|
+
The `supabase-test` framework provides powerful tools to simulate authentication contexts during tests, which is particularly useful when testing Row-Level Security (RLS) policies.
|
|
178
|
+
|
|
179
|
+
#### Setting Test Context
|
|
180
|
+
|
|
181
|
+
Use `setContext()` to simulate different user roles and JWT claims:
|
|
93
182
|
|
|
94
183
|
```ts
|
|
95
|
-
|
|
184
|
+
db.setContext({
|
|
185
|
+
role: 'authenticated',
|
|
186
|
+
'jwt.claims.user_id': '123',
|
|
187
|
+
'jwt.claims.org_id': 'acme'
|
|
188
|
+
});
|
|
189
|
+
```
|
|
96
190
|
|
|
97
|
-
|
|
98
|
-
|
|
99
|
-
|
|
100
|
-
|
|
101
|
-
|
|
102
|
-
|
|
103
|
-
|
|
104
|
-
|
|
105
|
-
|
|
106
|
-
|
|
107
|
-
|
|
191
|
+
This applies the settings using `SET LOCAL` statements, ensuring they persist only for the current transaction and maintain proper isolation between tests.
|
|
192
|
+
|
|
193
|
+
#### Testing Role-Based Access
|
|
194
|
+
|
|
195
|
+
```ts
|
|
196
|
+
describe('authenticated role', () => {
|
|
197
|
+
beforeEach(async () => {
|
|
198
|
+
db.setContext({ role: 'authenticated' });
|
|
199
|
+
await db.beforeEach();
|
|
200
|
+
});
|
|
201
|
+
|
|
202
|
+
afterEach(() => db.afterEach());
|
|
203
|
+
|
|
204
|
+
it('runs as authenticated', async () => {
|
|
205
|
+
const res = await db.query(`SELECT current_setting('role', true) AS role`);
|
|
206
|
+
expect(res.rows[0].role).toBe('authenticated');
|
|
207
|
+
});
|
|
108
208
|
});
|
|
109
209
|
```
|
|
110
210
|
|
|
111
|
-
|
|
211
|
+
#### Database Connection Options
|
|
112
212
|
|
|
113
|
-
|
|
213
|
+
For non-superuser testing, use the connection options described in the [options](#getconnections-options) section. The `db.connection` property allows you to customize the non-privileged user account for your tests.
|
|
214
|
+
|
|
215
|
+
Use `setContext()` to simulate Role-Based Access Control (RBAC) during tests. This is useful when testing Row-Level Security (RLS) policies. Your actual server should manage role/user claims via secure tokens (e.g., setting `current_setting('jwt.claims.user_id')`), but this interface helps emulate those behaviors in test environments.
|
|
216
|
+
|
|
217
|
+
#### Common Testing Scenarios
|
|
218
|
+
|
|
219
|
+
This approach enables testing various access patterns:
|
|
220
|
+
- Authenticated vs. anonymous user access
|
|
221
|
+
- Per-user data filtering
|
|
222
|
+
- Admin privilege bypass behavior
|
|
223
|
+
- Custom claim-based restrictions (organization membership, admin status)
|
|
224
|
+
|
|
225
|
+
> **Note:** While this interface helps simulate RBAC for testing, your production server should manage user/role claims via secure authentication tokens, typically by setting values like `current_setting('jwt.claims.user_id')` through proper authentication middleware.
|
|
226
|
+
|
|
227
|
+
### 🌱 Seeding System
|
|
228
|
+
|
|
229
|
+
The second argument to `getConnections()` is an optional array of `SeedAdapter` objects:
|
|
114
230
|
|
|
115
231
|
```ts
|
|
116
|
-
|
|
232
|
+
const { db, teardown } = await getConnections(getConnectionOptions, seedAdapters);
|
|
233
|
+
```
|
|
117
234
|
|
|
118
|
-
|
|
119
|
-
|
|
235
|
+
This array lets you fully customize how your test database is seeded. You can compose multiple strategies:
|
|
236
|
+
|
|
237
|
+
* [`seed.sqlfile()`](#-sql-file-seeding) – Execute raw `.sql` files from disk
|
|
238
|
+
* [`seed.fn()`](#-programmatic-seeding) – Run JavaScript/TypeScript logic to programmatically insert data
|
|
239
|
+
* [`seed.csv()`](#️-csv-seeding) – Load tabular data from CSV files
|
|
240
|
+
* [`seed.json()`](#️-json-seeding) – Use in-memory objects as seed data
|
|
241
|
+
* [`seed.sqitch()`](#️-sqitch-seeding) – Deploy a Sqitch-compatible migration project
|
|
242
|
+
* [`seed.launchql()`](#-launchql-seeding) – Apply a LaunchQL module using `deployFast()` (compatible with sqitch)
|
|
243
|
+
|
|
244
|
+
> ✨ **Default Behavior:** If no `SeedAdapter[]` is passed, LaunchQL seeding is assumed. This makes `supabase-test` zero-config for LaunchQL-based projects.
|
|
245
|
+
|
|
246
|
+
This composable system allows you to mix-and-match data setup strategies for flexible, realistic, and fast database tests.
|
|
247
|
+
|
|
248
|
+
### 🔌 SQL File Seeding
|
|
249
|
+
|
|
250
|
+
Use `.sql` files to set up your database state before tests:
|
|
251
|
+
|
|
252
|
+
```ts
|
|
253
|
+
import path from 'path';
|
|
254
|
+
import { getConnections, seed } from 'supabase-test';
|
|
255
|
+
|
|
256
|
+
const sql = (f: string) => path.join(__dirname, 'sql', f);
|
|
257
|
+
|
|
258
|
+
let db;
|
|
259
|
+
let teardown;
|
|
260
|
+
|
|
261
|
+
beforeAll(async () => {
|
|
262
|
+
({ db, teardown } = await getConnections({}, [
|
|
263
|
+
seed.sqlfile([
|
|
264
|
+
sql('schema.sql'),
|
|
265
|
+
sql('fixtures.sql')
|
|
266
|
+
])
|
|
267
|
+
]));
|
|
268
|
+
});
|
|
269
|
+
|
|
270
|
+
afterAll(async () => {
|
|
271
|
+
await teardown();
|
|
272
|
+
});
|
|
120
273
|
```
|
|
121
274
|
|
|
122
|
-
###
|
|
275
|
+
### 🧠 Programmatic Seeding
|
|
123
276
|
|
|
124
|
-
|
|
277
|
+
Use JavaScript functions to insert seed data:
|
|
125
278
|
|
|
126
279
|
```ts
|
|
127
280
|
import { getConnections, seed } from 'supabase-test';
|
|
281
|
+
|
|
282
|
+
let db;
|
|
283
|
+
let teardown;
|
|
284
|
+
|
|
285
|
+
beforeAll(async () => {
|
|
286
|
+
({ db, teardown } = await getConnections({}, [
|
|
287
|
+
seed.fn(async ({ pg }) => {
|
|
288
|
+
await pg.query(`
|
|
289
|
+
INSERT INTO users (name) VALUES ('Seeded User');
|
|
290
|
+
`);
|
|
291
|
+
})
|
|
292
|
+
]));
|
|
293
|
+
});
|
|
294
|
+
```
|
|
295
|
+
|
|
296
|
+
## 🗃️ CSV Seeding
|
|
297
|
+
|
|
298
|
+
You can load tables from CSV files using `seed.csv({ ... })`. CSV headers must match the table column names exactly. This is useful for loading stable fixture data for integration tests or CI environments.
|
|
299
|
+
|
|
300
|
+
```ts
|
|
128
301
|
import path from 'path';
|
|
302
|
+
import { getConnections, seed } from 'supabase-test';
|
|
129
303
|
|
|
130
|
-
const
|
|
304
|
+
const csv = (file: string) => path.resolve(__dirname, '../csv', file);
|
|
305
|
+
|
|
306
|
+
let db;
|
|
307
|
+
let teardown;
|
|
308
|
+
|
|
309
|
+
beforeAll(async () => {
|
|
310
|
+
({ db, teardown } = await getConnections({}, [
|
|
311
|
+
// Create schema
|
|
312
|
+
seed.fn(async ({ pg }) => {
|
|
313
|
+
await pg.query(`
|
|
314
|
+
CREATE TABLE users (
|
|
315
|
+
id SERIAL PRIMARY KEY,
|
|
316
|
+
name TEXT NOT NULL
|
|
317
|
+
);
|
|
318
|
+
|
|
319
|
+
CREATE TABLE posts (
|
|
320
|
+
id SERIAL PRIMARY KEY,
|
|
321
|
+
user_id INT REFERENCES users(id),
|
|
322
|
+
content TEXT NOT NULL
|
|
323
|
+
);
|
|
324
|
+
`);
|
|
325
|
+
}),
|
|
326
|
+
// Load from CSV
|
|
327
|
+
seed.csv({
|
|
328
|
+
users: csv('users.csv'),
|
|
329
|
+
posts: csv('posts.csv')
|
|
330
|
+
}),
|
|
331
|
+
// Adjust SERIAL sequences to avoid conflicts
|
|
332
|
+
seed.fn(async ({ pg }) => {
|
|
333
|
+
await pg.query(`SELECT setval(pg_get_serial_sequence('users', 'id'), (SELECT MAX(id) FROM users));`);
|
|
334
|
+
await pg.query(`SELECT setval(pg_get_serial_sequence('posts', 'id'), (SELECT MAX(id) FROM posts));`);
|
|
335
|
+
})
|
|
336
|
+
]));
|
|
337
|
+
});
|
|
131
338
|
|
|
132
|
-
|
|
133
|
-
|
|
134
|
-
|
|
135
|
-
|
|
136
|
-
])
|
|
137
|
-
|
|
339
|
+
afterAll(() => teardown());
|
|
340
|
+
|
|
341
|
+
it('has loaded rows', async () => {
|
|
342
|
+
const res = await db.query('SELECT COUNT(*) FROM users');
|
|
343
|
+
expect(+res.rows[0].count).toBeGreaterThan(0);
|
|
344
|
+
});
|
|
138
345
|
```
|
|
139
346
|
|
|
140
|
-
##
|
|
347
|
+
## 🗃️ JSON Seeding
|
|
141
348
|
|
|
142
|
-
|
|
349
|
+
You can seed tables using in-memory JSON objects. This is useful when you want fast, inline fixtures without managing external files.
|
|
143
350
|
|
|
144
|
-
|
|
145
|
-
|
|
146
|
-
* `seed` - Seeding adapters (sqlfile, csv, json, launchql, sqitch, etc.)
|
|
147
|
-
* `DbAdmin` - Database administration utilities
|
|
351
|
+
```ts
|
|
352
|
+
import { getConnections, seed } from 'supabase-test';
|
|
148
353
|
|
|
149
|
-
|
|
354
|
+
let db;
|
|
355
|
+
let teardown;
|
|
150
356
|
|
|
151
|
-
|
|
357
|
+
beforeAll(async () => {
|
|
358
|
+
({ db, teardown } = await getConnections({}, [
|
|
359
|
+
// Create schema
|
|
360
|
+
seed.fn(async ({ pg }) => {
|
|
361
|
+
await pg.query(`
|
|
362
|
+
CREATE SCHEMA custom;
|
|
363
|
+
CREATE TABLE custom.users (
|
|
364
|
+
id SERIAL PRIMARY KEY,
|
|
365
|
+
name TEXT NOT NULL
|
|
366
|
+
);
|
|
367
|
+
|
|
368
|
+
CREATE TABLE custom.posts (
|
|
369
|
+
id SERIAL PRIMARY KEY,
|
|
370
|
+
user_id INT REFERENCES custom.users(id),
|
|
371
|
+
content TEXT NOT NULL
|
|
372
|
+
);
|
|
373
|
+
`);
|
|
374
|
+
}),
|
|
375
|
+
// Seed with in-memory JSON
|
|
376
|
+
seed.json({
|
|
377
|
+
'custom.users': [
|
|
378
|
+
{ id: 1, name: 'Alice' },
|
|
379
|
+
{ id: 2, name: 'Bob' }
|
|
380
|
+
],
|
|
381
|
+
'custom.posts': [
|
|
382
|
+
{ id: 1, user_id: 1, content: 'Hello world!' },
|
|
383
|
+
{ id: 2, user_id: 2, content: 'Graphile is cool!' }
|
|
384
|
+
]
|
|
385
|
+
}),
|
|
386
|
+
// Fix SERIAL sequences
|
|
387
|
+
seed.fn(async ({ pg }) => {
|
|
388
|
+
await pg.query(`SELECT setval(pg_get_serial_sequence('custom.users', 'id'), (SELECT MAX(id) FROM custom.users));`);
|
|
389
|
+
await pg.query(`SELECT setval(pg_get_serial_sequence('custom.posts', 'id'), (SELECT MAX(id) FROM custom.posts));`);
|
|
390
|
+
})
|
|
391
|
+
]));
|
|
392
|
+
});
|
|
152
393
|
|
|
153
|
-
|
|
394
|
+
afterAll(() => teardown());
|
|
395
|
+
|
|
396
|
+
it('has loaded rows', async () => {
|
|
397
|
+
const res = await db.query('SELECT COUNT(*) FROM custom.users');
|
|
398
|
+
expect(+res.rows[0].count).toBeGreaterThan(0);
|
|
399
|
+
});
|
|
400
|
+
```
|
|
401
|
+
|
|
402
|
+
## 🏗️ Sqitch Seeding
|
|
154
403
|
|
|
155
|
-
*
|
|
156
|
-
|
|
157
|
-
|
|
404
|
+
*Note: While compatible with Sqitch syntax, LaunchQL uses its own high-performance [TypeScript-based deploy engine.](#-launchql-seeding) that we encourage using for sqitch projects*
|
|
405
|
+
|
|
406
|
+
You can seed your test database using a Sqitch project but with significantly improved performance by leveraging LaunchQL's TypeScript deployment engine:
|
|
407
|
+
|
|
408
|
+
```ts
|
|
409
|
+
import path from 'path';
|
|
410
|
+
import { getConnections, seed } from 'supabase-test';
|
|
158
411
|
|
|
159
|
-
|
|
412
|
+
const cwd = path.resolve(__dirname, '../path/to/sqitch');
|
|
160
413
|
|
|
414
|
+
beforeAll(async () => {
|
|
415
|
+
({ db, teardown } = await getConnections({}, [
|
|
416
|
+
seed.sqitch(cwd)
|
|
417
|
+
]));
|
|
418
|
+
});
|
|
419
|
+
```
|
|
420
|
+
|
|
421
|
+
This works for any Sqitch-compatible module, now accelerated by LaunchQL's deployment tooling.
|
|
422
|
+
|
|
423
|
+
## 🚀 LaunchQL Seeding
|
|
424
|
+
|
|
425
|
+
If your project uses LaunchQL modules with a precompiled `launchql.plan`, you can use `supabase-test` with **zero configuration**. Just call `getConnections()` — and it *just works*:
|
|
426
|
+
|
|
427
|
+
```ts
|
|
428
|
+
import { getConnections } from 'supabase-test';
|
|
429
|
+
|
|
430
|
+
let db, teardown;
|
|
431
|
+
|
|
432
|
+
beforeAll(async () => {
|
|
433
|
+
({ db, teardown } = await getConnections()); // 🚀 LaunchQL deployFast() is used automatically - up to 10x faster than traditional Sqitch!
|
|
434
|
+
});
|
|
435
|
+
```
|
|
436
|
+
|
|
437
|
+
This works out of the box because `supabase-test` uses the high-speed `deployFast()` function by default, applying any compiled LaunchQL schema located in the current working directory (`process.cwd()`).
|
|
438
|
+
|
|
439
|
+
If you want to specify a custom path to your LaunchQL module, use `seed.launchql()` explicitly:
|
|
440
|
+
|
|
441
|
+
|
|
442
|
+
```ts
|
|
443
|
+
import path from 'path';
|
|
444
|
+
import { getConnections, seed } from 'supabase-test';
|
|
445
|
+
|
|
446
|
+
const cwd = path.resolve(__dirname, '../path/to/launchql');
|
|
447
|
+
|
|
448
|
+
beforeAll(async () => {
|
|
449
|
+
({ db, teardown } = await getConnections({}, [
|
|
450
|
+
seed.launchql(cwd) // uses deployFast() - up to 10x faster than traditional Sqitch!
|
|
451
|
+
]));
|
|
452
|
+
});
|
|
453
|
+
```
|
|
454
|
+
|
|
455
|
+
## Why LaunchQL's Approach?
|
|
456
|
+
|
|
457
|
+
LaunchQL provides the best of both worlds:
|
|
458
|
+
|
|
459
|
+
1. **Sqitch Compatibility**: Keep your familiar Sqitch syntax and migration approach
|
|
460
|
+
2. **TypeScript Performance**: Our TS-rewritten deployment engine delivers up to 10x faster schema deployments
|
|
461
|
+
3. **Developer Experience**: Tight feedback loops with near-instant schema setup for tests
|
|
462
|
+
4. **CI Optimization**: Dramatically reduced test suite run times with optimized deployment
|
|
463
|
+
|
|
464
|
+
By maintaining Sqitch compatibility while supercharging performance, LaunchQL enables you to keep your existing migration patterns while enjoying the speed benefits of our TypeScript engine.
|
|
465
|
+
|
|
466
|
+
## `getConnections` Options
|
|
467
|
+
|
|
468
|
+
This table documents the available options for the `getConnections` function. The options are passed as a combination of `pg` and `db` configuration objects.
|
|
469
|
+
|
|
470
|
+
### `db` Options (PgTestConnectionOptions)
|
|
471
|
+
|
|
472
|
+
| Option | Type | Default | Description |
|
|
473
|
+
| ------------------------ | ---------- | ---------------- | --------------------------------------------------------------------------- |
|
|
474
|
+
| `db.extensions` | `string[]` | `[]` | Array of PostgreSQL extensions to include in the test database |
|
|
475
|
+
| `db.cwd` | `string` | `process.cwd()` | Working directory used for LaunchQL/Sqitch projects |
|
|
476
|
+
| `db.connection.user` | `string` | `'app_user'` | User for simulating RLS via `setContext()` |
|
|
477
|
+
| `db.connection.password` | `string` | `'app_password'` | Password for RLS test user |
|
|
478
|
+
| `db.connection.role` | `string` | `'anonymous'` | Default role used during `setContext()` |
|
|
479
|
+
| `db.template` | `string` | `undefined` | Template database used for faster test DB creation |
|
|
480
|
+
| `db.rootDb` | `string` | `'postgres'` | Root database used for administrative operations (e.g., creating databases) |
|
|
481
|
+
| `db.prefix` | `string` | `'db-'` | Prefix used when generating test database names |
|
|
482
|
+
|
|
483
|
+
### `pg` Options (PgConfig)
|
|
484
|
+
|
|
485
|
+
Environment variables will override these options when available:
|
|
486
|
+
|
|
487
|
+
* `PGHOST`, `PGPORT`, `PGUSER`, `PGPASSWORD`, `PGDATABASE`
|
|
488
|
+
|
|
489
|
+
| Option | Type | Default | Description |
|
|
490
|
+
| ------------- | -------- | ------------- | ----------------------------------------------- |
|
|
491
|
+
| `pg.user` | `string` | `'postgres'` | Superuser for PostgreSQL |
|
|
492
|
+
| `pg.password` | `string` | `'password'` | Password for the PostgreSQL superuser |
|
|
493
|
+
| `pg.host` | `string` | `'localhost'` | Hostname for PostgreSQL |
|
|
494
|
+
| `pg.port` | `number` | `5423` | Port for PostgreSQL |
|
|
495
|
+
| `pg.database` | `string` | `'postgres'` | Default database used when connecting initially |
|
|
496
|
+
|
|
497
|
+
### Usage
|
|
498
|
+
|
|
499
|
+
```ts
|
|
500
|
+
const { conn, db, teardown } = await getConnections({
|
|
501
|
+
pg: { user: 'postgres', password: 'secret' },
|
|
502
|
+
db: {
|
|
503
|
+
extensions: ['uuid-ossp'],
|
|
504
|
+
cwd: '/path/to/project',
|
|
505
|
+
connection: { user: 'test_user', password: 'secret', role: 'authenticated' },
|
|
506
|
+
template: 'test_template',
|
|
507
|
+
prefix: 'test_',
|
|
508
|
+
rootDb: 'postgres'
|
|
509
|
+
}
|
|
510
|
+
});
|
|
511
|
+
```
|
|
161
512
|
|
|
162
513
|
## Related LaunchQL Tooling
|
|
163
514
|
|
|
@@ -202,4 +553,5 @@ All other functionality is identical to `pgsql-test`.
|
|
|
202
553
|
|
|
203
554
|
AS DESCRIBED IN THE LICENSES, THE SOFTWARE IS PROVIDED "AS IS", AT YOUR OWN RISK, AND WITHOUT WARRANTIES OF ANY KIND.
|
|
204
555
|
|
|
205
|
-
No developer or entity involved in creating this software will be liable for any claims or damages whatsoever associated with your use, inability to use, or your interaction with other users of the code, including any direct, indirect, incidental, special, exemplary, punitive or consequential damages, or loss of profits, cryptocurrencies, tokens, or anything else of value.
|
|
556
|
+
No developer or entity involved in creating this software will be liable for any claims or damages whatsoever associated with your use, inability to use, or your interaction with other users of the code, including any direct, indirect, incidental, special, exemplary, punitive or consequential damages, or loss of profits, cryptocurrencies, tokens, or anything else of value.
|
|
557
|
+
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "supabase-test",
|
|
3
|
-
"version": "0.0.
|
|
3
|
+
"version": "0.0.8",
|
|
4
4
|
"author": "Interweb <developers@interweb.io>",
|
|
5
5
|
"description": "supabase-test offers isolated, role-aware, and rollback-friendly PostgreSQL environments for integration tests with Supabase defaults baked in",
|
|
6
6
|
"main": "index.js",
|
|
@@ -54,7 +54,7 @@
|
|
|
54
54
|
"dependencies": {
|
|
55
55
|
"@launchql/types": "^2.6.1",
|
|
56
56
|
"pg-env": "^1.1.0",
|
|
57
|
-
"pgsql-test": "^2.11.
|
|
57
|
+
"pgsql-test": "^2.11.9"
|
|
58
58
|
},
|
|
59
|
-
"gitHead": "
|
|
59
|
+
"gitHead": "7aeb70c79619545d937597b64af80962803f6901"
|
|
60
60
|
}
|