From: | raf <raf(at)raf(dot)org> |
---|---|
To: | pgsql-general(at)lists(dot)postgresql(dot)org |
Subject: | Re: Are stored procedures/triggers common in your industry |
Date: | 2022-04-21 23:12:38 |
Message-ID: | YmHk5qajymooVgkz@raf.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Thu, Apr 21, 2022 at 08:42:10AM -0500, Alex Aquino <alex(at)efficiencygeek(dot)com> wrote:
> You mentioned testing, and reminds me of another benefit. Way faster, more
> reliable, cheaper to test on the DB side. Testing logic in SPs or SQL is
> much easier, especially when testing requires a sequence of calls for a use
> case. It is easier because of the DBs support for transactions. With
> transactions and state management built into the DB, a testing process can
> always revert to a reliable starting point and end point, thereby
> facilitating more dependable, automated test harnesses. The alternative
> done mostly now is testing via UIs or APIs where there is no inherent
> transaction management, so a lot of work goes into preparing the test bed
> to be a known state and introspecting the results to verify. This is
> usually done with some mix of manual and automated processes.
Actually, my full work tests take ages to run (~40m).
I know that mocking the db to make unit tests fast is popular,
but that's not helpful when the most important code being tested
is in the database. :-) It's more important to me that the tests
actually test everything than that they be fast.
But yes, being able to do complex system testing with transaction
rollback is great.
cheers,
raf
From | Date | Subject | |
---|---|---|---|
Next Message | Shaozhong SHI | 2022-04-21 23:21:17 | Configuration and performance of Postgres/PostGIS |
Previous Message | Radoslav Nedyalkov | 2022-04-21 21:25:42 | set column statistics to max does not help |