

Postgression - A PostgreSQL database for every test case - willlll
http://www.postgression.com/

======
rdegges
Hey all, so I'm one of the authors of postgression. The website isn't totally
clear as to all the reasons why this may be useful. I've written a blog post
about it, which you may also find helpful if you're interested:

[http://rdegges.com/postgression-a-postgresql-database-for-
ev...](http://rdegges.com/postgression-a-postgresql-database-for-every)

~~~
peeters
Thanks, I was confused about the motivation and that cleared it up. I think
the slogan "A PostgreSQL Database for Every Test Case" is clouding the purpose
for me. It sounds from that slogan like you've solved the problem of having a
clean database state for each test in your test suite by creating a new ad-hoc
database for each test case. But everything I've read, mostly from you, seems
to suggest that this is not about solving that problem at all, but rather
making it easy to spin up a clean, ad-hoc database with no installation
necessary.

So I'm really curious how that slogan is meant to be understood.

~~~
rdegges
Should probably redo the slogan. It kinda rhymed so we picked it, but it
obviously isn't that accurate :) A better slogan might be 'Testing Database as
a Service' or something like that.

------
Titanous
I'm not convinced that the cumulative latency this would introduce into test
runs is lower than the amount of time required to use brew or apt-get to
install Postgres.

~~~
rdegges
Hi Titanous, you're definitely right--the focus of postgression isn't speed,
just convenience.

Installing a database server locally to run unit tests is something that has
always annoyed me. 99.99% of the time when I'm testing things, I'm at a
computer, hooked up to the internet, working on things--and I'm usually not
all that concerned about an extra second of overhead.

I think the real benefit to this is that you can use the same DB harness
regardless of where you're testing: locally, Jenkins, Travis-CI, whatever.
This way, you don't have to write any code to make databases, check
credentials, whatever, it's just a thoughtless process.

~~~
nirvdrum
Sorry, I'm trying to wrap my head around the workflow. Do you use vagrant or
something for tests? Othrewise, wouldn't you need the DB installed locally to
run your site locally?

~~~
rdegges
I always use a remote db for developing my site locally (eg: Heroku
PostgreSQL). On my laptop I typically install my libraries (in a Python
virtualenv), and do coding.

------
pvh
You know what would make this faster? If you ran your tests inside Heroku as
well. Then you wouldn't have all the network round-trip time and you'd be test
in the same environment you go to production on.

------
olefoo
This may be a small nit, especially since this is specifically a public test
facility. But you might want to restrict the guest roles to only access their
own database public schema.

I can't see other's query activity, but I can see some of the pg_catalog
tables.

For instance

    
    
        select count(*) from pg_stat_database;
         count 
       -------
         1900
       (1 row)

~~~
zaidos
By default, Heroku allows roles on their shared database plans to view limited
info about databases on the same machine. Stuff like name, type and owner are
visible.

Here is a sample response when attempting to do anything with a database other
than your own:

FATAL: permission denied for database "xxxxxxxxxxxx" DETAIL: User does not
have CONNECT privilege. Previous connection kept

------
meaty
Not sure I'd want to throw my schema out of our infrastructure.

At the moment, our integration test run takes nearly two hours but this is
rolling out the schema and the sheer number of test cases (we have over 1
million lines of test cases). Something that speeds it up would be welcome but
this is not for us.

~~~
rdegges
Oh yah, this would definitely not be ideal for something like that.

In regards to the schema stuff, however, we don't touch any user data at all.
I've actually added a section to the bottom of our website:
<http://www.postgression.com/> which explicitly states our policy:

"In regards to security: postgression does not look at, log, or use any data
stored by our users. All data is completely ephemeral, and disappears after 30
minutes."

------
benatkin
This is inefficient on multiple levels. Please check out Vagrant.

~~~
rdegges
Hi there, so I'm one of the dudes that built this. Just saw in on HN, so
figured I'd respond.

We built this to combat the pain of testing in multiple locations. Sure, it
adds an extra second to the start of each test run, and sure, you have to talk
to a public database server, but the benefits you get are:

\- No database server needs to be running on your local machine, vagrant,
jenkins instance, or travis CI instance. This means one test configuration and
you can run the tests anywhere.

\- No need to write scaffolding code to make testing work with vagrant,
jenkins, etc., again--things _just work_.

It's certainly not suitable for everyone, but it fits my personal use case
well, which is why I decided to build it ^^

------
phusuke
Good job guys! This is pretty cool!

------
dmishe
Interesting, but still this is connecting to outside server. For mac there's
Postgres.app

~~~
rdegges
Definitely! Postgres.app is awesome, but this is kinda targeting a difference
use case (I'm one of the postgression authors).

This is really meant so that you don't need to run PostgreSQL at all locally.
It adds a small bit of overhead, but makes it much easier to run tests
locally, on a remote server (Jenkins, Travis CI, etc.), and doesn't require
any scaffolding code to create a db, etc. It just works :)

