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

[Randy Syring]

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 
> <mailto: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  <mailto: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
>     <mailto:testing-in-python at lists.idyll.org>
>     http://lists.idyll.org/listinfo/testing-in-python
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.idyll.org/pipermail/testing-in-python/attachments/20150404/99d66da6/attachment.htm>