| From: | Daniel Gustafsson <daniel(at)yesql(dot)se> |
|---|---|
| To: | Simon Connah <simon(dot)n(dot)connah(at)protonmail(dot)com> |
| Cc: | "pgsql-general(at)lists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: PostgreSQL DB in prod, test, debug |
| Date: | 2024-02-14 10:25:48 |
| Message-ID: | 7304F877-D043-4395-867E-014F48EB71ED@yesql.se |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
> On 14 Feb 2024, at 10:59, Simon Connah <simon(dot)n(dot)connah(at)protonmail(dot)com> wrote:
> This is probably a stupid question so I apologies in advance.
There is no such thing.
> What I think is the best way to do this is to do a pg_dump of the database (using the --schema-only flag) and then load it into a test only database that gets created at the start of the unit tests and destroyed at the end. The automated tests will insert, update, delete and select data to test if it all still works.
If the source of truth for your schema is the database, then sure. If the
source of truth is a .sql file in your source code repository then you should
use that. In essence, create the test database identically to how you create
the production database to ensure that you are testing what you will run in
production.
--
Daniel Gustafsson
| From | Date | Subject | |
|---|---|---|---|
| Next Message | arun chirappurath | 2024-02-14 10:30:07 | Postgres pg_cron extension |
| Previous Message | Simon Connah | 2024-02-14 09:59:01 | PostgreSQL DB in prod, test, debug |