[TIP] (announcing) pg13, an in-process SQL database for mocking

Abe Winter awinter.public at gmail.com
Sat Apr 4 14:48:28 PDT 2015


If you're deleting all tables (and sequences, indexes, etc) before
every test I'm guessing that's an okay isolation guarantee.

Re: overhead, creating a database is pretty cheap in pg13. It's just a
class instance with one dictionary. Running (or even parsing) a query
is more expensive than creating the DB.

On Sat, Apr 4, 2015 at 2:20 AM, Randy Syring <randy at thesyrings.us> wrote:
> I guess I should have been more specific in my question.  This seems like a
> heck of a lot of overhead to ensure your tests run without side effects.
> Other options that come to mind:
>
> if your schema is stable, just delete all data in relevant tables before
> starting the test (or all tables, if you must)
> delete all your DB objects, use the same DB
>
> We use the first method, namely, that a test is responsible for clearing any
> DB objects first, before it is run, if data in those objects could possibly
> interfere with the test.  So, for example:
>
> If a test wants to make sure a record is inserted using a record count on
> the table, then it must delete all records in that table before starting (or
> count the records that exist beforehand).
> If a test wants to edit an existing record and make sure the edit was
> successful, then no reason to clear other records in the DB.
>
> I'm just curious what kind of situations you are encountering where the
> overhead of creating a new DB for every test is better than one of the above
> methods (or some variant).
>
> I could see the need for multiple databases if you were running tests in
> parallel.
>
> Randy Syring
> Husband | Father | Redeemed Sinner
>
> "For what does it profit a man to gain the whole world
> and forfeit his soul?" (Mark 8:36 ESV)
>
> On 04/02/2015 11:05 PM, Alexandre Conrad wrote:
>
> Test isolation by avoiding artifact data potentially generated by other
> tests that didn't cleanup properly for whatever reason and could fail
> subsequent tests.
>
> On Apr 2, 2015 7:13 PM, "Randy Syring" <randy at thesyrings.us> wrote:
>>
>> Discussion: what's the point of creating a new database for *every* test?
>>
>> Randy Syring
>> Husband | Father | Redeemed Sinner
>>
>> "For what does it profit a man to gain the whole world
>> and forfeit his soul?" (Mark 8:36 ESV)
>>
>> On 04/02/2015 09:32 PM, Abe Winter wrote:
>>
>> Hi,
>>
>> I'm presenting pg13, a new python library for SQL mocking. It's fast
>> enough to create a new pure-python, in-memory DB for each test. It's
>> not complete or mature but supports enough of the basics to get good
>> coverage on a simple app.
>>
>> Performance is around ~200 tests per second on my hardware. This is vs
>> 1 test per second if you're creating a postgres DB per test;
>> in-process also parallelizes more easily. Sqlite on :memory: can be
>> quick but sqlite is not feature-compatible other SQL engines and is
>> hard to modify (90k lines of C). pg13's whole SQL engine is under 1000
>> lines, pure python, and easy to extend.
>>
>> More here:
>>
>> https://github.com/abe-winter/pg13-py
>>
>> Thanks,
>>
>> Abe Winter
>>
>> _______________________________________________
>> testing-in-python mailing list
>> testing-in-python at lists.idyll.org
>> http://lists.idyll.org/listinfo/testing-in-python
>>
>>
>>
>> _______________________________________________
>> testing-in-python mailing list
>> testing-in-python at lists.idyll.org
>> http://lists.idyll.org/listinfo/testing-in-python
>>
>



More information about the testing-in-python mailing list